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

[Michael Hafen]

Calling out to atomic files would be a good idea.  It only partially
alleviates merge conflicts though, because the reference to the file
still have to appear in updatedatabase.pl.  You would end up missing an
entire update rather than potentially messing up part of an update with
a merge conflict.  Missing the update is probably the better outcome
though, and the updatedatabase.pl file will be much smaller that way.

So having atomic update files, referenced from updatedatabase.pl, for
large updates (several lines of code) would be part of my proposal.

As for having do() and undo() in the included file... It's a nice idea,
but in practice un-deleting a column can be difficult.  Imagine trying
to reverse the database changes from the labels rewrite or the
acquisitions rewrite.

I think that standard practice for updating is to backup the database
first.  Then restore from the backup if there is a problem.  This
practice falls flat though if you don't notice the problem right away.
In which case having an undo() would be preferable.  But it would be
totally dependent on being able to pull the information from somewhere
to fill the un-deleted column.

Really the reason I don't like the idea is because I'm lazy.  That
practically doubles the work it takes to change the database.

Comments?

On Thu, 2010-01-28 at 22:46 +0100, LAURENT Henri-Damien wrote:
> Michael Hafen a écrit :
> > Update order.  I hadn't thought of that.  That could be a big deal.
> >
> >   
> Well it could be important at some point :
> you cannot update a field which doesnot exist.
> And so on....
> > I'm already committed to writing it if it does get traction.  I have a
> > couple database updates in my own branch that couldn't be in the the
> > updatedatabase.pl obviously.  If this does get traction and we can
> > figure out the patch order thing I'll want this a lot.
> >
> >   
> Another thing that I like about your idea is that it could point to 
> atomic change files...
> Easily test-able, easily indentified in a hierarchy of folders.
> BibLibre-Lyon-1 could make call for instance to biblibre/Lyon/1.pl ...
> Therefore, we would not end up with having merge conflicts.
> 
> 
> Maybe we could add to pl file a do and undo function so that...
> we can do and undo those updates. (But this is just day dreaming, just 
> before going to bed.)
> I can't wait for your proposal :P
> 
> My two cents though ;)


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