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

[Michael Hafen]

I'm still thinking about this.  The only thing I've come up with so far
is to enclose all the database updates in a subroutine, and put the code
from kohaversion.pl into updatedatabase.pl.  That would make one less
file to edit.  And if the few sub's at the end of updatedatabase.pl were
moved to the top of the file, and the kohaversion stuff put at the
bottom, then the sql would end up right above the version number.  That
way it might be more likely that the version number would be kept up to
date with the sql.

The other thought I have is to dump the updatedatabase.pl entirely.
Have a file that lists what the system preferences are supposed to look,
and another file that lists what the database is supposed to look like.
Then when the version number changes these files can be run to check if
the actual sys.pref. / database state matches the expected sys.pref. /
database state.  This would be much more complex though, especially the
database stuff.  If I know off hand how to easily find out exactly how a
certain column looks, like it's type and such, this would be easier.
We'd just have to make the script able to compose sql to add / drop /
modify columns.  It's very complex, but makes a nice option.  There
would be no question about the database state for a given version
number.  On the other hand this would make database changes very
difficult to backport to the maintenance branches.

So that's where my thoughts are at the moment.  Any comments here?

On Wed, 2010-02-03 at 11:59 -0500, Galen Charlton wrote:
> Hi,
> 
> 2010/2/3 Joe Atzberger <ohiocore at gmail.com>:
> > On Tue, Feb 2, 2010 at 6:30 PM, Michael Hafen <mdhafen at tech.washk12.org>
> > wrote:
> > 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.
> 
> Quickly, from my point of view the main things I'd like to see in a
> revised database update system are:
> 
> * the ability to end up with a linear set of database updates in
> released versions, for the reasons Joe mentions
> * secondarily, the ability to have a linear path in HEAD
> * a reduction in purely textual merge conflicts - splitting up the
> monolithic updatedatabase.pl would go a long way to address this
> * a better way to manage database updates that are backported to the
> maintenance branch
> * a mechanism to allow a developer to readily renumber updates that
> they're working on in a topic branch when it comes time to submit to
> HEAD
> * getting simple system preference updates out of the main
> 
> Regards,
> 
> Galen


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