[Koha-devel] patches with DB change, workflow

[Ian Walls]

I think the problem with database revision numbers comes down to something
fundamentally structural.  Database revision numbers are linear, and are
part of the Koha version number.  But our development is non-linear; using
Git, we work off Directed Acyclic Graphs.  There are multiple paths to reach
the same destination.  Trying to map the more complex DAG of our development
down to a linear sequence is the source of this difficulty.

So, what we need is to separate the mechanisms.  What if we pulled out the
database revision out of the version number, and used a hash of some kind to
identify the current database structure?  The hash could be calculated off
the kohastructure.sql, which is where any structural conflicts would arise
anyway.  I think it'd be safe enough to ignore system preferences and other
data, so long as the structure of all the database tables was factored in.

This would allow us to apply patches with database revisions without getting
'out of order', as well as allow us to get to the same structure in multiple
ways (like we can with code in Git).

I suppose the difficulty here would be keeping kohastructure.sql synced with
the database revision statements in updatedatabase.pl.  Perhaps there's a
way to just edit kohastructure.sql, then do a delta to generate the update
statements required?

Further thoughts?  Am I missing something critical (I have this nagging
feeling I am).


-Ian

On Wed, May 25, 2011 at 1:15 AM, LAURENT Henri-Damien <laurenthdl at alinto.com
> wrote:

> Le 23/05/2011 14:48, Chris Nighswonger a écrit :
> > Hi Paul,
> >
> > On Mon, May 23, 2011 at 8:17 AM, Paul Poulain <paul.poulain at biblibre.com
> > <mailto:paul.poulain at biblibre.com>> wrote:
> >
> >     Hi all,
> >
> >     I think there are some things unclear (at least for me ;-) ) about
> >     submitting bugs with DB changes.
> >
> >
> > <snip>
> >
> >
> >     * we spoke of using XXXX in updatedatabase.pl
> >     <http://updatedatabase.pl> to have te RM pick the
> >     right number when needed.
> >
> >
> >
> > Speaking from the prospective of Release Maintainer, this method works
> > the most consistent for me. I have very few times when a DB update patch
> > using the 3.NN.XXX format does not apply cleanly for me. This includes
> > cases where NN == some subversion other than the current maintenance
> > version. So with this, my workflow goes like this:
> >
> > 1. Apply patch/cherry pick.
> > 2. Adjust rev number.
> > 3. Commit rev number change.
> > 4. Go on to the next patch.
> >
> > On the rare occasion the original patch does not apply cleanly it takes
> > all of about one minute to fixup.
> >
> > So my vote is to use this method unless there is a very compelling
> > reason to do otherwise.
> OK.
>
> When you have something that should apply both to 3.2 and 3.4 (say an
> index change, or a change on a field (text to varchar or varchar to text
> or varchar 10 to varchar 255), you number that from which number ?) Do
> you keep the least number or do you use two different rev numbers ?
> If you keep both, when upgrading, you will have some unwanted issue raised.
> If you take the least, then the number of the revision in the master
> branch is not the correct one, and when ppl upgrade they either will
> loose some db changes or have duplicate numbers.
> It can be solved with a kind of "deduplication table".
> But rather uneasy to implement.
> Could be also solved with a variable that says... ok if you come from
> 3.2 then it is that number, 3.4 that other... But upgrade path will have
> to decide which path you are coming from.
>
> I don't have THE solution.
>
> I mean I had the problem with 3.0 to 3.2 and the "best way" (in terms of
> time/development/tests) to cope with it was to store the initial
> kohaversion and make a test. (see MT2308b on our git.)
>
> Keep up the good job Chris.
>
> But this is an old issue, and some points were made back in 2010 in a
> thread named How about a different way of handling database updates
> http://www.mail-archive.com/koha-devel@lists.koha.org/msg03423.html
>
> Problem with patches and contributions more and more numerous will raise
> that again.
>
> My 2 cents.
> --
> Henri-Damien LAURENT
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
>



-- 
Ian Walls
Lead Development Specialist
ByWater Solutions
ALA Booth 732
Phone # (888) 900-8944
http://bywatersolutions.com
ian.walls at bywatersolutions.com
Twitter: @sekjal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20110525/d8f2f744/attachment-0001.htm>