Echo JS 0.11.0

<~>
tracker1 1954 days ago. link parent 1 point
I don't have any boilerplate or an article to show, but my approach is usually as follows.  These are regardless of the specific dbms, I've done it with MS-SQL and MySQL, I'd presume it should be an adaptable approach for Postres as well.

Have a directory for DB versions... this directory will then have a .js file for each version, it will export a default and optionally a rollback.

When the application first loads, it will run a pre-init db script that will first create an AppSettings key/value table, if it doesn't exist, where the key is nvarchar, and the value is json.  It will then check for a current version, setting it to 0, if there isn't a record.

The current version is compared against the directories, and if the current version is less than the directories indicate, it will get/set a *LOCK* record (mutex) in the database, then check again.  The *LOCK* will retry in a loop to set the mutex/lock record to its' own id, and after finished, delete that record.  After comparing again, it will run through each update script.

Each update script will be run, if no errors, then the version record will be updated to the current version.  If there is an error, and a rollback export exists, it will be run, and the application will log an output, and terminate.

After all updates have ran, and the lock record is cleared, the application will continue to start.  Optional: If it's a service, start the service, but return 503 responses until the database is updated.

This approach allows any number of deploys of the application/api to get the database to the current version, and the locking prevents more than one instance from trying to run updates.

It's worked out really well for me in applications I've built.  It's a bit of manual work for the setup, but after a few DB versions/releases tends to become more than worth it.  It also tends to be simpler than using some of the DB/version management tools.

Replies