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

[LAURENT Henri-Damien]

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 ;)
-- 
Henri-Damien LAURENT
> The patch order may not be that big a deal.  There is an implicit patch
> order enforced by the patches location in the updatedatabase.pl file.
>   
> That might be good enough.
>   
> On Thu, 2010-01-28 at 18:29 +0100, Paul Poulain wrote:
>   
>> Kyle Hall a écrit :
>>     
>>> The naming convention sounds very reasonable. Very java import styled.
>>> Very good idea.
>>>
>>> Now the big question is, can we get any traction for such a big
>>> change? Is there anyone else willing to comment on the possbility of
>>> this idea?
>>>   
>>>       
>> create a syspref (with TEXT, we have a lot of space).
>> Separate each patch applied with a comma :
>>
>> BibLibre-1,mhafenA,someoneElse,anotherone,BibLibre-2, ...
>>
>> need to check that a patch has been applied ? just =~ /BibLibre-1,/ if 
>> not applied, apply it, and add BibLibre-1, at the end of applied 
>> patches. The order doesn't matter.
>>
>> (well, in fact, the order may matter, and that may be the limit of this 
>> idea...)
>>
>>     
>
>
>