"Joshua M. Ferraro" <jmf@liblime.com> wrote: [...]
I'd also like to point out that updatedatabase should start completely blank for 3.0. IMO updatedatabase shouldn't be the upgrade path from 1.x or 2.x to 3.0 ... rather, it should be the upgrade path for 3.0 to 3.2, etc. Other thoughts?
I thought updatedatabase started as the upgrade path from 2.0 to 2.2 or similar. How will 2.2 users upgrade to 3.0 if not updatedatabase?
I'd like to get feedback from everyone on the best way to maintain kohastructure.sql and updatedatabase, to make sure we always have a known SQL definition and update process. Comments, ideas?
Firstly, the dumps should be made with the same options. How about: LANG=C mysqldump -cnQ koha >kohastructure.sql ?
My second suggestion is more radical: kohastructure.sql should only be changed in a branch by the release manager. Ideally, that would only happen with each release at most. At all other times, ALTER statements and other transformations should be added to an upgrade file, say called kohastructure-3.0.0.sql, then kohastructure-3.0.1.sql - or should it be .pl and done with DBI commands?
If included in the release, they could also be the basis of the database upgrade, just running that one change file for each release. Yea, this is a great idea. Right now, it's near impossible to weed through updatedatabase to try to figure out all the changes
----- "MJ Ray" <mjr@phonecoop.coop> wrote: that have been made to a given table, etc. What we need is a really simple way to view all the changes and apply them, and one person who's responsible for maintaining the official definition. So what we need is to figure out what the authoritative SQL def looks like for 3.0 ... any volunteers? :-) -- Joshua Ferraro SUPPORT FOR OPEN-SOURCE SOFTWARE President, Technology migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf@liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS