Live data from Hacker News

It’s fine, Rewind: Revert a migration without losing data

planetscale.com

21–30 of 39 posts

Re: It’s fine, Rewind: Revert a migration without losing data

#21
"We are giving away limited-edition, retro Rewind t-shirts to the first 100 people that successfully revert a schema change."

they are encouraging people to record videos of making schema changes and reverting them, in order to win a t-shirt

does this seem unnecessarily risky or in really poor taste to anyone else?

Re: It’s fine, Rewind: Revert a migration without losing data

#22

"We are giving away limited-edition, retro Rewind t-shirts to the first 100 people that successfully revert a schema change." they are encouraging people to record videos of making schema changes and reverting them, in order to win a t-shirt does this seem unnecessarily risky or in really poor taste to anyone else?

Hopefully someone is doing this in testing or staging.

Re: It’s fine, Rewind: Revert a migration without losing data

#23

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…

Engineer at PlanetScale; If you drop columns that are `NOT NULL DEFAULT `, 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…

This is why you should put minimal consistency checks in your DB directly. Put them in your storage later instead.

Re: It’s fine, Rewind: Revert a migration without losing data

#24

Earlier quoted context omitted.

that’s awesome but when would it be useful? wouldn’t that lead to data loss?

Engineer at PlanetScale; it will let you go back to safety without data loss, and without making your database inconsistent. If you will indulge a realistic story; I've been through this process multiple times in production. You change a large table via ALTER TABLE; you possibly change a data type, or drop a column, or modify an index. The change takes 5 hours to complete - and things go bad. Testing in staging was g…

This is a really clear description of the problem and solution. Thanks!

I recommend amending the blog (or maybe making a new post) with this exact content. I regularly run SQL databases for smaller projects but was not able to immediately conceptualize how I would use this feature from just the blog post. Maybe your target audience would be able to? But I don't see the downside in just spelling it out clearly!

Re: It’s fine, Rewind: Revert a migration without losing data

#26

Earlier quoted context omitted.

Engineer at PlanetScale; If you drop columns that are `NOT NULL DEFAULT `, 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…

This is why you should put minimal consistency checks in your DB directly. Put them in your storage later instead.

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.

Re: It’s fine, Rewind: Revert a migration without losing data

#27
post #13

Earlier quoted context omitted.

Sounds a bit iffy if your prod deployment fails after testing… surely the correct way is to have staging pickup any issues prior to prod

lol. I mean, yes... but also - have you really never seen a bug make it to production?

Yes - but this kinda gives it an easy pass. Makes it easier to ‘move fast and break things’ which isn’t always best

Re: It’s fine, Rewind: Revert a migration without losing data

#29

Earlier quoted context omitted.

Engineer at PlanetScale; If you drop columns that are `NOT NULL DEFAULT `, 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…

This is why you should put minimal consistency checks in your DB directly. Put them in your storage later instead.

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.

Re: It’s fine, Rewind: Revert a migration without losing data

#30

"We are giving away limited-edition, retro Rewind t-shirts to the first 100 people that successfully revert a schema change." they are encouraging people to record videos of making schema changes and reverting them, in order to win a t-shirt does this seem unnecessarily risky or in really poor taste to anyone else?

I think that's the point. Schema migration is traditionally a _very_ risky thing but they're trying to make it come off as "safe", if you're a PlanetScale customer.
Post reply on HN