41–50 of 69 posts
Such is life. This perspective seems coming from an application developer who is seeing the database as an extension of the app. When you're big enough to have a database ops team, they will come with a different perspective, and most likely be highly skeptical of storing schema changes in the database. If your're not too cool for MySQL, check out skeema.io for a declarative, platform-agnostic approach to schema mana…
I still think that for many cases, small to medium enterprises should consider migrations with downtime. If it’s B2B it’s relatively normal to have maintenance periods.
I think the Heisenberg uncertainty principle applies to database migrations. You can migrate or you can have no downtime, you cannot do both.
Earlier quoted context omitted.
Former DBA here turned Python dev (flask mostly) and now Data Engineer: 1 million percent this: “ 1. rollbacks are bullshit, stop pretending they aren't. They work fine for easy changes, but you can't rollback the hard ones (like deleting a field), and you're better off getting comfortable with forward-only migrations” Think of database migrations like you would versioning an API, deprecate and then drop old columns…
> Think of database migrations like you would versioning an API, deprecate and then drop old columns only after declaring a breaking change and giving consumers time. This ties into my second point as I eventually made an "api_v2" database schema and migrated users as you describe.
Earlier quoted context omitted.
You can, but I'd argue if your API schema is just 1-to-1 views for the underlying tables, you're not getting much value from this approach.
Until you change the underlying tables, or the api schema. At which point you don’t need to change the other.
What I've done instead is change the underlying table as needed, and ensure the view interface stays the same, by changing the view definition. This lets you refactor the low-level schema without breaking clients, and this migration can be done in a single transaction.
Two additional rules I don't see followed often, but made a past life of mine much easier: 1. rollbacks are bullshit, stop pretending they aren't. They work fine for easy changes, but you can't rollback the hard ones (like deleting a field), and you're better off getting comfortable with forward-only migrations 2. never expose real tables to an application. Create an "API" schema which contains only views, functions,…
I always wonder why this pattern is not more popular: https://sive.rs/pg We try to put a clean API on everything, except the one place where it really matters...
Two additional rules I don't see followed often, but made a past life of mine much easier: 1. rollbacks are bullshit, stop pretending they aren't. They work fine for easy changes, but you can't rollback the hard ones (like deleting a field), and you're better off getting comfortable with forward-only migrations 2. never expose real tables to an application. Create an "API" schema which contains only views, functions,…
I always wonder why this pattern is not more popular: https://sive.rs/pg We try to put a clean API on everything, except the one place where it really matters...
Chasing our tech-tail.
Earlier quoted context omitted.
I always wonder why this pattern is not more popular: https://sive.rs/pg We try to put a clean API on everything, except the one place where it really matters...
SQL is the clean interface. Databases are not designed to run your extra business computations, they are there to store and give you access to your data with efficiency and some guarantees. DBMS' are impossible to debug, cannot be shut down like you would with a faulty service node, and locking/crashing the production one can grind your entire company to a halt. The above pattern seems insane to me.
Such is life. This perspective seems coming from an application developer who is seeing the database as an extension of the app. When you're big enough to have a database ops team, they will come with a different perspective, and most likely be highly skeptical of storing schema changes in the database. If your're not too cool for MySQL, check out skeema.io for a declarative, platform-agnostic approach to schema mana…
Your comment is written like you have a undisclosed stake in skeema.io
Skeema is used by several hundred companies, including GitHub, Twilio, and Etsy. We have a lot of fans in the MySQL community, and just because someone enjoys the product does not mean they’re a shill.
Two additional rules I don't see followed often, but made a past life of mine much easier: 1. rollbacks are bullshit, stop pretending they aren't. They work fine for easy changes, but you can't rollback the hard ones (like deleting a field), and you're better off getting comfortable with forward-only migrations 2. never expose real tables to an application. Create an "API" schema which contains only views, functions,…
I have a question regarding this point:
> 2. never expose real tables to an application. Create an "API" schema which contains only views, functions, procedures, and only allow applications to use this schema.
Would a view-based indirection help with rollbacks? For example, in scenarios where a column is added/dropped, would it work to just join with a new relationship column? Rolling back would consist of updating the view to include/exclude the join operation, and the old data would remain in place.