I'm still thinking about this. The only thing I've come up with so far is to enclose all the database updates in a subroutine, and put the code from kohaversion.pl into updatedatabase.pl. That would make one less file to edit. And if the few sub's at the end of updatedatabase.pl were moved to the top of the file, and the kohaversion stuff put at the bottom, then the sql would end up right above the version number. That way it might be more likely that the version number would be kept up to date with the sql.
The other thought I have is to dump the updatedatabase.pl entirely. Have a file that lists what the system preferences are supposed to look, and another file that lists what the database is supposed to look like. Then when the version number changes these files can be run to check if the actual sys.pref. / database state matches the expected sys.pref. / database state. This would be much more complex though, especially the database stuff. If I know off hand how to easily find out exactly how a certain column looks, like it's type and such, this would be easier. We'd just have to make the script able to compose sql to add / drop / modify columns. It's very complex, but makes a nice option. There would be no question about the database state for a given version number. On the other hand this would make database changes very difficult to backport to the maintenance branches. So that's where my thoughts are at the moment. Any comments here? On Wed, 2010-02-03 at 11:59 -0500, Galen Charlton wrote: > Hi, > > 2010/2/3 Joe Atzberger <ohioc...@gmail.com>: > > On Tue, Feb 2, 2010 at 6:30 PM, Michael Hafen <mdha...@tech.washk12.org> > > wrote: > > I realize I haven't been pushing code towards Koha for maybe half a year > > now, but I honestly don't think that DB revisions were a big enough problem > > to have us abandon the advantages of the current approach without a more > > pronounced incentive. > > Quickly, from my point of view the main things I'd like to see in a > revised database update system are: > > * the ability to end up with a linear set of database updates in > released versions, for the reasons Joe mentions > * secondarily, the ability to have a linear path in HEAD > * a reduction in purely textual merge conflicts - splitting up the > monolithic updatedatabase.pl would go a long way to address this > * a better way to manage database updates that are backported to the > maintenance branch > * a mechanism to allow a developer to readily renumber updates that > they're working on in a topic branch when it comes time to submit to > HEAD > * getting simple system preference updates out of the main > > Regards, > > Galen -- 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
