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

[Michael Hafen]

Reply inline.

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.

> 
> 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.

> 
> 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.  
> 

This is a good suggestion.  I like the idea of having a seperate system
preference to track proprietary database revisions.  It doesn't have the
benefit of making public database updates easier to coordinate, because
we would still be using a numeric comparison.  There would still be
version number stomping for the RM to sort out in submitted patches.

But I do think it is a good alternative.

> 
> 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.
> 

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

It will mean more work for developers in testing their updates.  I'll
grant that as the price to pay against the "I got next" problem.  I'm
willing to pay that price.

> 
> --Joe Atzberger
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha.org
> http://lists.koha.org/mailman/listinfo/koha-devel

Thanks for your comments.  This is the kind of discussion I was hoping
for.  Here we have a good alternative to my proposal in the separate
system preference to track proprietary database revisions.


-- 
Michael Hafen
Systems Analyst and Programmer
Washington County School District
Utah, USA

for Koha checkout
http://development.washk12.org/gitweb/
or
git://development.washk12.org/koha