-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le 23/11/2011 17:02, Marcel de Rooy a écrit :
Quote from Bugzilla #7167 Here is how it works: * each database update is stored in a numbered file, in installer/data/mysql/versions * database updates can be .sql or .pl files. 2 skeletons are provided to explain how it works * there is no more automatic checking of the database update on each page. The librarian/sysadmin must go to the admin/updatedatabase.pl page on each update. * the updatedatabase.pl script keep track of all updates that have been applied, how it went. And it's non-linear: 3.7.2.3 can be applied after 3.7.2.4 * The about.pl will display the highest db update applied, but maybe there are some missing, it's only the highest applied [End of quote]
My questions are now: How do I submit a new db update? just create a file under installer/data/mysql/versions
I cannot give it a number myself; in that case somebody else could have a patch pending using that number already. So I assume that the RM renames the file. What convention do we use? yes you can : as it's not linear, you can. To know which numbers have been "reserved", we could have a wiki page. If you've reserved 3.07.01.017 and someone has a 3.07.01.018, the 018 can be pushed *before* your 017, there's no problem with that.
Is there still a check at login time if all updates have been run which redirects to the update screen? no. Because it takes a long time to check all versions, and, as it's unlinearized, you must check each version, not just check you've the "highest number"
I would say that we do not need that check everywhere, but I would keep it at login time. This idea could be investigated for someone that log-in with admin permission, for example. Does others think it's a must-have ? Here at BibLibre, most of us think checking the database update is a part of an update, so if it's not made, it means you're doing a poor job.
Would you allow an admin to install only partially the updates? Isn't that asking for trouble? yes, you could. Even if, I agree, that would be a strange idea. And that's why there is a [UPDATE] on the top that update everything
It is not linear, but some patches with db updates will be sensitive to the order applied. Is there any logic to prevent problems in that area? Nope, and we discussed a lot of this during hackfest, there is no solution for this. Plus, investigating actual updatedatabase show only a few cases that could cause a problem. 90% of the updates are syspref/index/foreign keys related.
HTH - -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOzSVIAAoJEK81SonuhyGo4JAIAJWxr3IMX8OgxDU2a4QNgwQD BRcKqNQDTG3YJneW7CRh959wglzk2gABQdiKcZqoO0XrAKNnqxaEinrpWbbTq63p 4yev1h8A1RFYwMYjtHSsFtdJFDWBf6XWPzHkl5gscPohPbFWteLBqeNePgTxXkh+ D4dPi6PG1HPK3iAt75tv26zruLA3Zn9DsML1Zhv0hvLqgsuFVobmXFA8R4OGRawm CGaPFD5NZW1PfHjqNdAC4Bfb0hrqd59q1+bTlsDcd2gJrePKelDmC8Yge2S9n3GN v/g+vWq0Vmmd1fdEfFWkui60iw9XJizKA0JFOpcq1Dzc5Z+OzQMelkxyHcYLtkM= =xN9m -----END PGP SIGNATURE-----