8 ms·
But I doubt unleashing the full expressive power of SQL is the point here. It would easily turn a moderately complicated "remove column" migration a real mainte
by kroolik 5y ago
But I doubt unleashing the full expressive power of SQL is the point here. It would easily turn a moderately complicated "remove column" migration a real maintenance hell.
In the simplest form, when you add a column to some schema, it should be materialized in the base schema and exposed via the migration view.
The problems start when you add and remove 20 columns because even though they are no longer visible in migration schemas, they take up space in the base schema
- fabianlindfors 5y agoYes, this approach might actually decrease the power of your database as some things become much trickier. It might be worth trading of some expressive power of the database for smoother, less hands-on migrations though, which is what I'm going for.
- lallysingh 5y agoThat sounds like problems upstream of this technique. Are you complaining that it isn't a silver bullet or that it's so powerful that it'll be abused?
- kroolik 5y ago@lallysingh, sorry, can't reply directly. All I'm saying is that I don't think we need a full Turing-complete cannonball to hit the (relatively) small fly of no-downtime migrations. Is it a silver-bullet? It's Turing-complete so high chances yes. But for me it has a high risk of causing a silver-poisoning. Personally, I would stick with simpler solutions.
- squiggleblaz 5y agoButting in to say: Maximum reply depth is relative to the view. Just click on the comment's time and you will get a form with a reply field.
- moreira 5y agoWOAH! I’ve been using HN for years and had NEVER realised that. And I honestly keep seeing people saying they can’t reply, either. This changes things!
- Sr_developer 5y agoLet's see how deep this rabbit-hole goes