IMPORTANT Koha 3.0 updatedatase and kohastructure.sql
Hi all, For years, we've had trouble maintaining the official Koha SQL definition, it seems like every developer probably has a slightly different definition. This is fine, however, we need to decide on an appropriate process for updating the official kohastructure.sql file that forms the basis for the new Web Installer in Koha 3.0. If you look back through the history of this file: http://cvs.savannah.nongnu.org/viewvc/koha/installer/kohastructure.sql?root=koha&view=log You'll notice vastly different versions ... people seem to just overwrite it with a new def exported in their favorite tool (mysqldump, phpmyadmin, etc.). Recently I had to revert kohastructure.sql in CVS because it patently failed for me ... I noticed that there are some definitions missing as well, and discrepancies between versions w/respect to the constraints. For instance, I asked Paul this afternoon to send me his 3.0 SQL definition, but that didn't include the 'defaultvalue' column in the marc_subfield_structure table, and, as a result, the MARC editor is broken for new installations when using that definition. 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'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? Cheers, -- 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
This seems to be a very serious problem. I thought it may have been just me for not updating from CVS frequently enough since I have not been contributing any code lately. Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com 212-674-3783 On Tue, July 3, 2007 7:07 pm, Joshua M. Ferraro wrote:
Hi all,
For years, we've had trouble maintaining the official Koha SQL definition, it seems like every developer probably has a slightly different definition. This is fine, however, we need to decide on an appropriate process for updating the official kohastructure.sql file that forms the basis for the new Web Installer in Koha 3.0. If you look back through the history of this file:
http://cvs.savannah.nongnu.org/viewvc/koha/installer/kohastructure.sql?root=koha&view=log
You'll notice vastly different versions ... people seem to just overwrite it with a new def exported in their favorite tool (mysqldump, phpmyadmin, etc.). Recently I had to revert kohastructure.sql in CVS because it patently failed for me ... I noticed that there are some definitions missing as well, and discrepancies between versions w/respect to the constraints.
For instance, I asked Paul this afternoon to send me his 3.0 SQL definition, but that didn't include the 'defaultvalue' column in the marc_subfield_structure table, and, as a result, the MARC editor is broken for new installations when using that definition.
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'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?
Cheers,
-- 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
_______________________________________________ Koha-devel mailing list Koha-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/koha-devel
"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. Comments, questions? Hope that helps, -- MJ Ray - see/vidu http://mjr.towers.org.uk/email.html Experienced webmaster-developers for hire http://www.ttllp.co.uk/ Also: statistician, sysadmin, online shop builder, workers co-op. Writing on koha, debian, sat TV, Kewstoke http://mjr.towers.org.uk/
On 4/07/2007, at 12:54 PM, MJ Ray wrote:
"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?
Hmm yeah, good question.
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 ?
I like it
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.
That sounds like a great idea, much easier to track changes, and it does allow an easy upgrade path. Chris -- Chris Cormack chris.cormack@liblime.com VP Research and Development www.liblime.com LibLime +64 21 542 131
"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
Joshua M. Ferraro a écrit : How did I miss that thread... sorry guys, I agree it's a very important topic. I'll continue the discussion on "Koha database structure meeting". -- Paul POULAIN et Henri Damien LAURENT Consultants indépendants en logiciels libres et bibliothéconomie (http://www.koha-fr.org) Tel : 04 91 31 45 19
participants (5)
-
Chris Cormack -
Joshua M. Ferraro -
MJ Ray -
Paul POULAIN -
Thomas Dukleth