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 _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
