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

[LAURENT Henri-Damien]

Michael Hafen a écrit :
>>> My opinion is that the current system is not that bad. The
>>>       
> dependency
>   
>>> graph is linear, date ordered by version number last digits. It just
>>> becomes crazy when updates are ported from one branch to the other, HEAD
>>> to maintenance for example. And there is (am I wrong?) to claim
>>> 'communitly' such a number:
>>>       
>> The problem with the wiki page for db number claiming is it doesn't
>> seem to work, at least it hasn't worked for me in the past. It assumes
>> that the features will be committed in the order that the db numbers
>> are claimed, which I don't believe is true. In that case, if the wiki
>> page were enforced, then db versions would be committed out of order,
>> and the updater would not work correctly. I just don't believe the
>> wiki page is effective at all. After having a number of db version
>> numbers stepped on, I stopped using it.
>>
>>     
>
> This is one of the two major concerns I have with the current system,
> and lead to my proposal.  The other concern is proprietary database
> updates, which are practically impossible with the current system
> because of this same problem of stomping on revision numbers.
>
> On Fri, 2010-01-29 at 13:58 +0100, Paul Poulain wrote: 
>   
>> Frederic Demians a écrit :
>>     
>>> Those kind of things can be tricky and messy. 
>>>       
I agree.
But they already are.
When one works on new features for 3.4 (see RFC for 3.4) and have to 
plan for DB updates, how does one deal with update database and rebase 
and merging ?

On the other hand, I agree I proposed things that could become very 
complicated.
But it was brain dumping and proposals.
I donot think the wiki has been much helpfull. It is quite difficult to 
plan how many updates you will need in order to bug fix and design a 
feature.
It could be in fact a simple text file in installer/data/mysql/ 
ticketsclaim.... But then, simply getting
But the fact is that it would not adress the fact that you can run 
multiple branches on the same codebase. And you would LOVE the merge to 
be the more seamless as possible.


As release maintainer for 3.0 I **had to*** create and arrange db 
updates in a different order than master branch. Knowing wich db version 
you were on 3.00.01 and not 3.01 was really important, even though its 
management could have been improved. (Things that would add some tables 
and maybe break features should never have mixed up with stable code.) 
It ended up to be VERY tricky and dangerous to only cherry pick bug 
fixes unless master code is really close to maintenance branch.
This lead to duplication of code. This would have been avoided if 
updatedatabase30.pl replaced updatedatabase.pl. But then, I would have 
had to cope with conflict at each cherry pick even if the commit would 
not update updatedatabase.pl.

Not to mention all the db changes that local users may want to do and track.

>> Other idea : shouldn't we open a new position, named "database 
>> consistency manager" or something like that ?
>>     
>
> I don't think having a DB Consistency Manager is going to help that
> much.  I don't think it would be much different from the wiki page.  It
> would be one person in charge instead of several people trying to
> coordinate.  But that person would still have a lot of work to do with
> changing patches or making patches of their own to keep database updates
> sane.
>