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? 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? Is there still a check at login time if all updates have been run which redirects to the update screen? I would say that we do not need that check everywhere, but I would keep it at login time. Would you allow an admin to install only partially the updates? Isn't that asking for trouble? 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? Marcel ________________________________________ Van: koha-devel-bounces@lists.koha-community.org [koha-devel-bounces@lists.koha-community.org] namens Paul Poulain [paul.poulain@biblibre.com] Verzonden: maandag 21 november 2011 8:52 Aan: koha-devel@lists.koha-community.org Onderwerp: Re: [Koha-devel] Update database changes proposal [IMPORTANT] -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le 20/11/2011 01:09, Mason James a écrit :
now.. how could an .SQL only solution achieve this? - its impossible, right?
- using .pl patches, with a *combination* of perl and sql, would allow us the best of both options - using .sql patches alone, means a patch won't be able to use any internal Koha subroutines?
Ian (& all): see my mail about what Jonathan has already written and that I should submit quickly (today ?) : he deals with both .sql and .pl, so we get the best of both worlds !!! (the updater detect the extension and work accordingly) 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/ iQEcBAEBAgAGBQJOygM/AAoJEK81SonuhyGo/G8H/3qJevFE40LXY9ei20toW720 TIMl8G2VSSFfIidSWDJW5B8z1EcNX2QUTMsWr0w5OIvpNgxTrWzcxBOox1DCfM4t W5ZhN39L0H4LuEmzIO/8Anmlsw4q2jDyUzFyJJcJf3dcag99tJDM1Pl1PP/nXG+b EbEkox73K7EEx1PNHsHea6VdcpZYThs+0OKRGsXdRFTOlYEMj4Im6lb/hUi3Q3P9 1rgrM3Y2EtAZ81z+1opkooIaVyjwCNw+cjNJUtZhblBMX6w7MtFkir2ne7oegCh4 CjiqQ++PaP1AT5Z7jz2cwvD6yKEVdoHG3JXQE3LaH4sFSDZaFLbKp9I9kNgutEk= =fUJh -----END PGP SIGNATURE----- _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/