You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This issue is mainly to collect design thoughts before i implement the feature.
The problem at hand is that there's currently no way to orchestrate updating the database schema if we try to change it. I'd like to tweak the database as part of #301, so if i can get this out of the way at the same time, all the better!
Current ideas:
we already have a database_version config value being stored - it's added and set to 1 when database init is run
a database upgrade command could inspect this value, then execute a series of queries that incrementally apply a change from one version to the next
if the config table is missing when database upgrade is run, fail the command and suggest running database init instead
if the config table is present but the database_version entry is missing, do nothing and exit with failure
if the database version matches the latest version, do nothing and exit with success
(this way, we can just put cratesfyi database upgrade in our deploy script and run it every time 😉)
if the database version is greater than the current version, do nothing and exit with failure
if the database version is less than the current version, load up the changes to make and apply them one-by-one, then update the version in the database
One question that's worth noting is whether we want to support downgrading? It doesn't seem too useful to keep around, but could come in handy.
The text was updated successfully, but these errors were encountered:
This issue is mainly to collect design thoughts before i implement the feature.
The problem at hand is that there's currently no way to orchestrate updating the database schema if we try to change it. I'd like to tweak the database as part of #301, so if i can get this out of the way at the same time, all the better!
Current ideas:
database_version
config value being stored - it's added and set to 1 whendatabase init
is rundatabase upgrade
command could inspect this value, then execute a series of queries that incrementally apply a change from one version to the nextconfig
table is missing whendatabase upgrade
is run, fail the command and suggest runningdatabase init
insteadconfig
table is present but thedatabase_version
entry is missing, do nothing and exit with failurecratesfyi database upgrade
in our deploy script and run it every time 😉)One question that's worth noting is whether we want to support downgrading? It doesn't seem too useful to keep around, but could come in handy.
The text was updated successfully, but these errors were encountered: