Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
@spacem exactly what we are doing for our security appliances. the benefit is, that you really can go from any version to the current one. only downside is that you cannot rollback in an easy way. so we decided to do snapshots of the db just before the update process. if the script goes wrong, then we have a rollback, and if the script is doing well, but the application misbehaves then we still can restore to the db snapshot.
I thought today was a good day to look at how I will deal with database migrations for this node.js/sql-server application. I read up docs for a few migration frameworks but the ones I found seem to make things too complex.
I am tempted to just roll my own by storing a db version in a table, numbering .sql scripts in a folder and running all the higher numbered scripts when the application starts.
Anyone know is there any gold standard for this sort of thing or anything to watch out for?
undefined
database-migration