mnamici
commented
2 years ago Ok after giving it some thought I think for our purpose it is enough to implement a simple mechanism like the following:
1) We assign a natural number to each schema refinement [1,+inf) and increment it at every change. We can store the current version using sqlite3 specific user_version pragma, designed specifically for this purpose (so no extra table needed).
2) We store the version the plugin expects in a db-version property in the plugin spec;
3) We manage in the plugin SQL migration statements between each incremental version;
4) At startup time we query the user_version pragma value and for any integer between user_version and db-version, we run the corresponding migration script;
5) Finally, we store db-version into user-version.
EDIT: I forgot to mention that this should already be implemented for v3.3 as we only need to set the initial user_version value for this release, a one-liner during schema creation. For later releases we will deal with the migration infrastructure.
Description
Design a versioning scheme for the ontology importer database, and provide an upgrade path from older versions.
Motivation
In future releases in may be the case that we change the schema in the ontology importer database. Since there is no way to restore it, and the user has no idea (and should not have) of this db existence and it's purpose, we would probably end up with bug reports related to the import process not working anymore.
Example Use Cases
The first thing that I can think of is to implement something like what is done for android or ios orm frameworks, probably a table with the latest db revision, and a set of SQL commands that perform the upgrade from one version to the next incrementally.
We could even consider introducing something like sqlalchemy if it helps, or write one with QtSql, or even ditch the orm entirely and use a different serialization format (but the upgrade problem still remains).