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

[Joe Atzberger]

On Tue, Feb 2, 2010 at 6:30 PM, Michael Hafen <mdhafen at tech.washk12.org>wrote:

> On Tue, 2010-02-02 at 16:50 -0500, Joe Atzberger wrote:
> > 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.
> >
>
> In simplest term what I want to do is replace a numeric comparison with
> a string comparison.  The ability to develop again a certain version
> number is intact, the difference is that the number becomes a string.



It doesn't matter whether it is a string or not.  Once you remove the
linearity of the update process, you no longer know what revision X means.
 You could have got there by applying X to:

   - 3.00.04.019,
   - 3.02.01.555,
   - "Z", or even
   - "2.00.00.01".

It means you have applied patch X, it does not mean *database state* X.  The
linearity of the process is why we happen to use numbers to describe it,
since numbers have an agreed-upon order.  That's why your approach would
need a log of every update applied AND the order of application instead of
just the version label.  Because if one revision "A" creates a table and
another "B" drops it if it exists, you get totally different results if you
run them AB vs. BA.

Currently 3.00.04.019 implies 3.00.04.018, 3.00.04.017, etc.  The proposed
scheme forces us to know the entire contents of the upgrade log to know the
database state.  That is to say, you need to READ the database, to know what
the database should look like.  This violates some distinctions we would
otherwise like to retain between structure and data.


> 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.
> >
>
> This isn't the RM's job, it is the developers.  It is currently the
> developers job to make sure his code is clean with other developers
> code.  That would still be the case either way.
>
> As you mention below there are other ways to handle proprietary database
> versioning.  So the problem already exists.  I'm sure the solution
> already exists too, which is for the kind and talented developers to
> make sure they test edge cases in their code and test new code against
> proprietary code.


It cannot be the developers job to know all other developers' unreleased
changes.  And it IS the RM's job to make sure each DB revision applies
cleanly to the previous one.  In the proposed scheme, instead of  "to the
previous one" that becomes "to any possible previous state".  And even
worse, "to any hypothetical state yet-to-be developed"!  There is no
guarantee that somebody else won't have made 100 revisions before trying to
apply the current one.

It will be a much harder job, whoever is doing it, combining complexity and
obscurity.  The result will be that the tester tests the previous state they
happen to have because it is ridiculous to imagine that they must then go
test against every DB schema being developed, or ever used, when all we
should care about is getting it to apply to one target (at HEAD).

I think we can work around the "I got next" problem by removing the
> numeric comparison from the equation.
>

Numeric or not, removing the linearity of updates means that "next" does not
exist.  The problem is that "previous" stops existing also.  I'm not against
considering new approaches to DB versioning, but on it's own this is not a
suitable alternative to me.

I realize I haven't been pushing code towards Koha for maybe half a year
now, but I honestly don't think that DB revisions were a big enough problem
to have us abandon the advantages of the current approach without a more
pronounced incentive.

--Joe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20100203/806d0489/attachment-0003.htm>