[Koha-devel] Update database changes proposal [IMPORTANT]

[Ian Walls]

For my part, I'm very excited about this change.  I think we're going to
have a much easier time of submitting database changes this way.  There
will be a learning curve for folks used to doing it the old way, but like
the change to using a common systempreferences.sql instead of one for each
language.  It'll make life easier, so I would assume adoption would occur
readily.  In the event it doesn't, the QA team could agree to reform
old-style submissions into the new style, at least for the rest of the 3.8
release cycle.

Any issues anyone can see with this approach, please bring them up.  We're
only a few at the hackfest, and need more opinions before we proceed.  But
I think this is going to work well, and solve several problems, while still
preserving the quick version checking we've already got.

Cheers,


-Ian

On Sat, Nov 5, 2011 at 2:55 AM, Paul Poulain <paul.poulain at biblibre.com>wrote:

> Hello,
>
> During the hackfest in Mumbaï, 5 of us had a brainstorming about
> database changes to try to improve it.
> Here are the goals:
> * must result in patches being easier to test by testers (to sign-off)
> * must result in less conflict when trying to apply a patch with a DB
> update when another patch has been applied (the .XXXX problem)
> * must fix the linear problem (where patches are applied in a completly
> linear way)
> * be easy to implement
>
>
> We throwed many ideas, here is the one that seems both easy and usefull :
> * patches would be submitted in a specific file, in atomicupdate directory
> * a new file (YAML) would be added, that would have 2 columns, one for
> the version number, one for the atomicupdate file name
> * updatedatabase wouldn't change anymore: we would just add something like
> :
> LoadYAMLFile()
> ForEachLine {
>    if (C4::Context->preference("Version") < FirstColumnYAML) {
>        exec(secondColumnYAML);
>        SetVersion (FirstColumnYAML);
>    }
> }
> The YAML file would be updated only by the Release Manager, when he
> pushes a patch.
>
> This idea fully achieve most of our initial goals:
> * (very) easy to implement
> * it will be easier to test a patch : is there an atomic update in the
> patch ? OK, to test it, i'll first execute the file
> * there won't be any conflict anymore of a patch applied and your .XXXX
> file not applying anymore, needing a rebase
> * it fixes partially the linear problem = if you have a local branch,
> you can see what has been applied just looking in the yaml file.
> Let's say Limoges library has sponsored stuff that has resulted in
> atomicupdate/limogeupdate.pl
> Those changes are live in Limoges, but still not in official/community
> version.
> The Limoges YAML file will be:
> 3.07.0001 Community_change1.pl
> 3.07.0002 community_change2.pl
> localchange limogesupdate.pl
> 3.07.0003 community_change3.pl
> the "localchange" in first column will mean for the updater : "OK, apply
> the change but don't change the version number"
>
> When the localchange has been applied on master community branch, the
> official/community YAML file will look like:
> 3.07.0001 Community_change1.pl
> 3.07.0002 community_change2.pl
> 3.07.0003 community_change3.pl
> 3.07.0004 limogesupdate.pl
>
> Switching back limoges to a community version would require some manual
> checking, but that will be *much* easier than what we have today :
> * diff limoges.yaml official.yaml
> * apply community changes if/where needed
> * UPDATE systempreferences SET kohaversion=3.07.0004 manually
> It's done !
>
> And if the localchange that has been made is never merged into master,
> whatever the reason, it will be easier to keep track of it too.
>
> And if you want to apply a submitted patch to your local setup before
> it's pushed onto master, you can, just by running the file in
> atomicupdate directory. And add a "localchange" line to your YAML file
> to remember the change you've made.
>
> Does anyone see a problem with this new updatedatabase procedure ?
> Until now, I have pushed no changes in database, so if we agree, i'll
> implement this change quickly (before pushing any change having a
> database consequence)
>
> --
> Paul POULAIN
> http://www.biblibre.com
> Expert en Logiciels Libres pour l'info-doc
> Tel : (33) 4 91 81 35 08
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
>



-- 
Ian Walls
Lead Development Specialist
ByWater Solutions
Phone # (888) 900-8944
http://bywatersolutions.com
ian.walls at bywatersolutions.com
Twitter: @sekjal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20111105/8269d90b/attachment.htm>