[Koha-devel] How about a different way of handling database updates

[Joe Atzberger]

There is one great advantage of the current approach, and that is that when
a user says "we are on Koha version X", you know exactly what the database
state for that should be.  You know the tables, fields, constraints AND the
codebase.  To be clear, that means that you can *do development* specified
against that version number.

Similarly, the RM only has to know that the next increment applies cleanly
to previous one.  He does not have to go hunting down edge cases where
DB-thread X and public-proprietary-thread Y conflict in the absence of some
random other thread Z.  I would advise that we should not relinquish this
advantage without serious consideration.  Once you get into mix/match
situation, the version number does NOT tell you the state of the database.

The way LibLime handled LEK updates was quite simple.  They had a different
syspref declaring the internal version number.  They batched all the
internal updates in a chunk at the end of the main updatedatabase body,
using the same kind of logic.  You should be able to find a commit by Ryan
where he adds some whitespace to updatedatabase to make it even easier to
delineate.  I suggest if you want to pursue it, that reimplementing that
with say LocalCustomVersion would be the simplest approach.  When the
customizer is ready to commit back to mainline, she can combine all the
local DB updates into one current KohaVersion update.

For comparison, let me mention DB updates for Evergreen.  Only after I
started working on it did Evergreen adopt any explicit DB versioning!  That
has been resolved using a script that processes individual incremental SQL
files:

http://svn.open-ils.org/trac/ILS/browser/trunk/Open-ILS/src/sql/Pg/upgrade


That system is pretty good.  However with multiple committers, the "I got
next" linearity is still a small problem.  So in the end, I think that is
just the price you pay for having the version number refer to a known DB
state.

--Joe Atzberger
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20100202/78d8b5ec/attachment-0003.htm>