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
We are working with a few different existing tables, updating the code to register them with Berlin. Usually, as part of that, we are also making some kind of adjustment to the table and expecting to run an upgrade routine.
What we have discovered is that if the database table exists but does not have a db_version value saved to the database, that the fallback version false results in no pending upgrades being collected, even though we need them to be.
One solution we've implemented in the past, but which feels hard, is to override the maybe_upgrade method and add additional checks to make sure the initial upgrades run. What feels a little itchy about this is that the additional checks just always have to run.
What I'd like to suggest is changing the default for the get_db_version method to be something numeric, rather than false. It wouldn't affect a brand new install, since the table is installed if it doesn't exist and then the database version is set, at which point the default db_version value is moot. But for an existing install which saved the database version to the options table in a non-Berlin format, like 1.0 or something, it seems like it would trigger the upgrade process (it is for me in some testing).
I'm working on this scenario and have set the database default to be 1 in our version of the Berlin code and it seems to be working as I need, without having to resort to overriding the rest of the upgrade functionality.
The text was updated successfully, but these errors were encountered:
robincornett
added a commit
to robincornett/berlindb-core
that referenced
this issue
Mar 23, 2023
We are working with a few different existing tables, updating the code to register them with Berlin. Usually, as part of that, we are also making some kind of adjustment to the table and expecting to run an upgrade routine.
What we have discovered is that if the database table exists but does not have a
db_version
value saved to the database, that the fallback versionfalse
results in no pending upgrades being collected, even though we need them to be.One solution we've implemented in the past, but which feels hard, is to override the
maybe_upgrade
method and add additional checks to make sure the initial upgrades run. What feels a little itchy about this is that the additional checks just always have to run.What I'd like to suggest is changing the default for the
get_db_version
method to be something numeric, rather than false. It wouldn't affect a brand new install, since the table is installed if it doesn't exist and then the database version is set, at which point the defaultdb_version
value is moot. But for an existing install which saved the database version to the options table in a non-Berlin format, like1.0
or something, it seems like it would trigger the upgrade process (it is for me in some testing).I'm working on this scenario and have set the database default to be
1
in our version of the Berlin code and it seems to be working as I need, without having to resort to overriding the rest of the upgrade functionality.The text was updated successfully, but these errors were encountered: