[Interest] SQLite
André Somers
andre at familiesomers.nl
Wed May 27 10:51:57 CEST 2015
Graham Labdon schreef op 27-5-2015 om 09:39:
> Hi
> I am planning to use a SQLite database in my application to store application data.
> The application is large and complex so we are taking a phased delivery approach. This will mean that the structure of the database will change over time and that we need to provide backwards compatibility.
> So, what I need is some way to create a versioning system and a way of converting old format databases to the current format.
> I would be grateful if anyone could suggest a good approach to this
>
> Thanks
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
We do it manually. We keep a data version number in the database
properties, which you can set and get via a pragma. Then, we have a list
of updater objects that can update a database from one version to the/a
next using a script. For every database change we need to make, we up
the version number we expect, update the code to create a new database
and write an updater script from the previous version. We run the
scripts we need to update to the version expected by the software at
startup. So, if you run the software against a version 7 database and
the software expects version 10, it will go through the scripts looking
for a script that updates version 7. The updater that takes a version 7
then updates to version 8, so the software will look for a script that
takes a version 8 database. This updater can then update to version 10
in for instance, skipping version 9 that may have been faulty in some
sense. It is quite easy to extend and reasonably flexible in terms of
making it possible to create scripts that skip version numbers if that
makes sense, but not make it mandatory to write a separate script
between each possible version.
Note that we don't support going backwards. That sometimes causes
problems when clients want to reinstall a previous version because of
some regression. We save backups of the database when we upgrade to help
us mitigate problems (we have had a faulty database update script once,
and that caused massive headaches to solve). A problem is that SQLite
only supports a small subset of the DDL. Changing tables is hardly
possible. That results in having to write more complicated scripts that
create a new table with the modified structure, and then copy over the
data from the old table, then delete the original table and rename the
new table to the old one. That is a procedure in which it is easy to
make a small mistake with big consequences. So I'd also advise to
instigate a strict code review policy on any changes to database
structure: every change, no matter who made it, needs a code review.
André
More information about the Interest
mailing list