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