3 ms·

This is pretty amazing. What are the restrictions on it working? For example, suppose we had a non-NULL column A which we drop in the migration, and new records

This is pretty amazing. What are the restrictions on it working? For example, suppose we had a non-NULL column A which we drop in the migration, and new records come in without A data. That works on the new table, but if you revert, presumably you would lose those records since they can't be added to the old schema. Does it prevent you from rolling back, or let you roll back to a modified previous schema that allows NULLs, or does it roll back and drop those new records?

shlomi-noach 5y ago
Engineer at PlanetScale; If you drop columns that are `NOT NULL DEFAULT <something>`, and then you insert some new rows to your newly-versioned table, then you're in a good spot: when you revert, those columns will get the DEFAULT value on those rows. If those columns were `NOT NULL` and with no DEFAULT, then you are unable to rewind. The rewind process will make an attempt -- after all, maybe you didn't add new rows; maybe you just deleted or updated -- but if you did INSERT new rows, then the Rewind process will fail (and you will be notified that rewind is impossible). There's a couple more interesting scenarios, see this doc page for more: https://docs.planetscale.com/concepts/deploy-requests https://docs.planetscale.com/concepts/deploy-requests
- omegalulw 5y ago
  This is why you should put minimal consistency checks in your DB directly. Put them in your storage later instead.
  - cesaref 5y ago
    So that you can cope with someone messing up a deployment and wanting to roll it back? Let's say you avoid column restrictions in your db design, and you deploy some dodgy code that doesn't fill in a column correctly, now you've got heaps of dubious data cluttering your database, and apps failing because some precondition isn't being met. That doesn't sound like a good compromise to avoid headaches when updating a schema, does it? So as ever, it's about making the right decisions on a case by case basis, and there is no 'one size fits all' for stuff like this.
  - mixedCase 5y ago
    That would create an explosion of code to handle edge cases that should never happen when interacting with the DB, or worse, pretending everything's alright and letting everything blow up in your face later.

shlomi-noach 5y ago

Engineer at PlanetScale; If you drop columns that are `NOT NULL DEFAULT <something>`, and then you insert some new rows to your newly-versioned table, then you're in a good spot: when you revert, those columns will get the DEFAULT value on those rows. If those columns were `NOT NULL` and with no DEFAULT, then you are unable to rewind. The rewind process will make an attempt -- after all, maybe you didn't add new rows; maybe you just deleted or updated -- but if you did INSERT new rows, then the Rewind process will fail (and you will be notified that rewind is impossible). There's a couple more interesting scenarios, see this doc page for more: https://docs.planetscale.com/concepts/deploy-requests https://docs.planetscale.com/concepts/deploy-requests

omegalulw 5y ago
This is why you should put minimal consistency checks in your DB directly. Put them in your storage later instead.
- cesaref 5y ago
  So that you can cope with someone messing up a deployment and wanting to roll it back? Let's say you avoid column restrictions in your db design, and you deploy some dodgy code that doesn't fill in a column correctly, now you've got heaps of dubious data cluttering your database, and apps failing because some precondition isn't being met. That doesn't sound like a good compromise to avoid headaches when updating a schema, does it? So as ever, it's about making the right decisions on a case by case basis, and there is no 'one size fits all' for stuff like this.
- mixedCase 5y ago
  That would create an explosion of code to handle edge cases that should never happen when interacting with the DB, or worse, pretending everything's alright and letting everything blow up in your face later.