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?
21–30 of 39 posts
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?
"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?
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…
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…
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!
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.
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.
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?
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.
"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?