Database Migrations
vadimkravcenko.com
Database Migrations
1–10 of 69 posts
Re: Database Migrations
#2Insightful. Also, your website design is very clean and nice - I like it.
Re: Database Migrations
#3This is really good.
It covers one of the most common things people miss with regards to running migrations: it isn't possible to atomically deploy both the migration and the application code that uses it. This means if you want to avoid a few seconds/minutes of errors, you need to deploy the migration first in a way that doesn't break existing code, then the application change, and then often a cleanup step to complete the migration in a way that won't break.
Knowing how to do this isn't a common skill. It's probably a good topic for an interview question for senior engineering roles.
Re: Database Migrations
#4Two 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, procedures, and only allow applications to use this schema. This gives you a layer of indirection on the DB side such that you can nearly eliminate the dance of coordinating application changes and database migrations
You can get away without these rules for a long time, but 2 becomes particularly useful when more than one application uses the database.
Re: Database Migrations
#5Two 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’d really like to implement 2. but it’s quite difficult to make the switch to that approach when you already have a ton of tables.
Re: Database Migrations
#6Insightful. Also, your website design is very clean and nice - I like it.
Very hard to read on mobile though. I either have to scroll left to right for every line, or zoom out and have very small text. Seems like the content div has a min-width or something that prevents the text from wrapping on a narrow screen.
Re: Database Migrations
#7Two 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,…
Rather than 2, isn't it better to let a single application own the database and manage the schema?
Re: Database Migrations
#8Such 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 management and path to happiness.
Re: Database Migrations
#9Two 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,…
Rather than 2, isn't it better to let a single application own the database and manage the schema?
That is the point of 2. The single application is the API.
Re: Database Migrations
#10Two 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,…
how does this work? you have the "real" database and this "api" database makes queries to the real database? how does that work?