Comment by bob1029 | Hacker News Reader

Comment by bob1029 | Hacker News Reader

We do something like this with SQLite.

Fun fact - you don't even need to maintain a special unicorn "_migrations" table or any other external state to keep track of things with SQLite migration. You can simply utilize the user_version pragma:

https://sqlite.org/pragma.html#pragma_user_version

We have a DatabaseVersion constant in the classes that own each type of SQLite database, and all they have to do at ctor time is query the database for current version and run a for loop over the difference to execute the required migration scripts.

Our migrators are one-way (we don't define a matching 'down.sql'). We would push new code to back something out of a SQL schema and then increment our counter just like if we added something new. Decrementing/skipping is disallowed since this would cause information loss on the migration path. Having a monotonic version number per type of database makes it super easy to keep everything on rails for us.

For database access, we also use raw SQL via Dapper.

I did something similar leveraging SQL table and DB comments. In hindsight a migrations table would've been easier to understand and maintain. Still I could see an incrementing counter working for resource constrained projects.

Do you prepare your rollback snippets in advance? If not, how do you deal with urgent rollbacks? If yes, how do you make sure those snippets work in advance?

The SQLite usage is very tightly integrated with the software. Any urgent rollback is effectively a roll-forward fix of whatever broken software is in production.

When I say urgent rollback I mean rollback within 30 seconds of realizing something went wrong. Do you have this capability?

Shouldn't you do DB updates in production in a way that N backend always works at least with N+1 schema? So you just rollback the backend...

Can you please explain this like I'm 5. I am still learning and I would like to understand how to do upgrades in a better way.

I'm not the original commenter, nor am I experienced with upgrading in general, but what I understand from the comment is that you always make sure that your current schema is compatible with the previous backend.

For example, this could mean that you don't delete any column that were still in use in the previous backend version.

This would have the advantage of letting you rollback your backend alone if anything wrong happens.

You could do it that way, but I don't have the need, so my way leads to faster dev cycle: https://news.ycombinator.com/item?id=29566574

Doing as you say requires two deployment for each change with a pause in between, and likely two separate merges (does it?). This reduces the deployment velocity. I might have to do as you describe when I start scaling out - there is no hope of updating many servers in sync so might as well embrace multi-version.

Reply on news.ycombinator.com