Hello. I just pushed bug 7167, which changes the way database updates work. I wrote up instructions for database updates at http://wiki.koha-community.org/wiki/Database_updates#Using_the_new_update_pr... Please be sure to read those instructions and follow them in the future. Regards, Jared -- Jared Camins-Esakov Bibliographer, C & P Bibliography Services, LLC (phone) +1 (917) 727-3445 (e-mail) jcamins@cpbibliography.com (web) http://www.cpbibliography.com/
I just pushed bug 7167, which changes the way database updates work. I wrote up instructions for database updates at http://wiki.koha-community.org/wiki/Database_updates#Using_the_new_update_pr...
Please be sure to read those instructions and follow them in the future.
Additionally, you will need to install File::Find::Rule Regards, Jared -- Jared Camins-Esakov Bibliographer, C & P Bibliography Services, LLC (phone) +1 (917) 727-3445 (e-mail) jcamins@cpbibliography.com (web) http://www.cpbibliography.com/
Hello.
I just pushed bug 7167, which changes the way database updates work. I wrote up instructions for database updates at http://wiki.koha-community.org/wiki/Database_updates#Using_the_new_update_pr...
Please be sure to read those instructions and follow them in the future.
Regards, Jared
Thank you very much Jared for the wiki page! I add some stuff in a new part to explain why I wrote this patch. I hope it could help some of you who are reluctant to the feature to change their mind :-) I am under the impression that everybody knows that the old method was bad but nobody wants to change it. I believe this patch is a great improvement for Koha and could simplify life for developers and Koha administrators. The first version of this patch was submitted 1 year ago and it was very hard to find contributors to develop it. The actual development certainly contains some lacks and bugs but I really hope some developers will find this feature cool and will propose further improvements. Please feel free to contribute and give me feedbacks (in a constructive way!) :-) Happy new year to all of you and see you in 2013! Freely, Jonathan
Le 27/12/2012 18:01, Jared Camins-Esakov a écrit :
Hello.
I just pushed bug 7167, which changes the way database updates work. I wrote up instructions for database updates at http://wiki.koha-community.org/wiki/Database_updates#Using_the_new_update_pr...
Please be sure to read those instructions and follow them in the future. Hi Jared, (and happy new year everyone !)
How should be handle pending patches with a DB update ? (question asked for each role : submitter, signer, QAer) Should someone update the patch to use the new DB update schema ? if no, how should/can we test patches with the old schema ? ( Thanks for pushing this patch though ! ) -- Paul POULAIN - BibLibre http://www.biblibre.com Free & Open Source Softwares for libraries Koha, Drupal, Piwik, Jasper
The patches were reverted (it broke installing) so no change yet I don't think . Also I will not be pushing it to 3.10.x so if anything is for 3.10.x and needs a db change, when this patch is pushed, we will need 2 sets of db changes. Chris On Jan 2, 2013 11:31 PM, "Paul Poulain" <paul.poulain@biblibre.com> wrote:
Le 27/12/2012 18:01, Jared Camins-Esakov a écrit :
Hello.
I just pushed bug 7167, which changes the way database updates work. I wrote up instructions for database updates at http://wiki.koha-community.org/wiki/Database_updates#Using_the_new_update_pr...
Please be sure to read those instructions and follow them in the future. Hi Jared, (and happy new year everyone !)
How should be handle pending patches with a DB update ? (question asked for each role : submitter, signer, QAer)
Should someone update the patch to use the new DB update schema ? if no, how should/can we test patches with the old schema ?
( Thanks for pushing this patch though ! )
-- Paul POULAIN - BibLibre http://www.biblibre.com Free & Open Source Softwares for libraries Koha, Drupal, Piwik, Jasper
_______________________________________________ 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/
Paul,
I just pushed bug 7167, which changes the way database updates work. I
wrote up instructions for database updates at http://wiki.koha-community.org/wiki/Database_updates#Using_the_new_update_pr...
Please be sure to read those instructions and follow them in the future. Hi Jared, (and happy new year everyone !)
How should be handle pending patches with a DB update ? (question asked for each role : submitter, signer, QAer)
Should someone update the patch to use the new DB update schema ? if no, how should/can we test patches with the old schema ?
( Thanks for pushing this patch though ! )
Once the needed follow-ups are signed off and the feature is re-pushed, it will be the responsibility of the QAer to copy the database update from updatedatabase.pl to a new-style update for SQL-only updates (for complex updates that are not simply copy-paste, we will probably have to send the patch back to the author for revision). For bugs that are not signed off, the author will need to move the database update, unless someone else volunteers to do it for them. Also, I have a correction to Chris's response: we will not need two separate sets of DB changes because I will be copying every non-linear update into updatedatabase.pl. That was the reason for the CheckVersion() routine. Regards, Jared -- Jared Camins-Esakov Bibliographer, C & P Bibliography Services, LLC (phone) +1 (917) 727-3445 (e-mail) jcamins@cpbibliography.com (web) http://www.cpbibliography.com/
Le 02/01/2013 15:15, Jared Camins-Esakov a écrit :
Also, I have a correction to Chris's response: we will not need two separate sets of DB changes because I will be copying every non-linear update into updatedatabase.pl <http://updatedatabase.pl>. That was the reason for the CheckVersion() routine.
Just to be sure I understand well. You will *copy* things into updatedatabase.pl when pushing to stable. Thus, we will have the patch in both old and new mechanism ? The koha 3.12 will use the new mechanism and 3.10.x will use the old one ? How will Koha behave for people upgrading from 3.10.x to 3.12 (once it's released, of course), where a db change will have been applied with the old mechanism and will be re-applied with the new one ? (I think the new mechanism will just issue an error message about, for example a "duplicate entry in XXX" or "already existing column YYYY" or "cannot find xxx" (because it has already been removed and cannot be removed again). If I'm right, then we just will have to warn in the new mechanism comment "if you see message xxx, it means this change had already been applied, and you can force apply it safely" For those who don't know how the new mechanism will work (internally) : each DB change, if there's an error thrown will appear as "failing", with the error message. The administrator can then "force apply" a DB revision. In this case, Koha will just mark "OK, this DB change is done" (happy new year again!) -- Paul POULAIN - Associé-gérant Tel : (33) 4 91 81 35 08 http://www.biblibre.com Logiciels Libres pour les bibliothèques et les centres de documentation
On Jan 3, 2013 3:15 AM, "Jared Camins-Esakov" <jcamins@cpbibliography.com> wrote:
Paul,
I just pushed bug 7167, which changes the way database updates work. I wrote up instructions for database updates at
Please be sure to read those instructions and follow them in the
future. Hi Jared, (and happy new year everyone !)
How should be handle pending patches with a DB update ? (question asked for each role : submitter, signer, QAer)
Should someone update the patch to use the new DB update schema ? if no, how should/can we test patches with the old schema ?
( Thanks for pushing this patch though ! )
Once the needed follow-ups are signed off and the feature is re-pushed, it will be the responsibility of the QAer to copy the database update from updatedatabase.pl to a new-style update for SQL-only updates (for complex updates that are not simply copy-paste, we will probably have to send the
http://wiki.koha-community.org/wiki/Database_updates#Using_the_new_update_pr... patch back to the author for revision). For bugs that are not signed off, the author will need to move the database update, unless someone else volunteers to do it for them.
Also, I have a correction to Chris's response: we will not need two
separate sets of DB changes because I will be copying every non-linear update into updatedatabase.pl. That was the reason for the CheckVersion() routine.
Hi While that is a good idea, and will mean the packages aren't totally busted on master. A commit that has both the old safe updatedatabase and the new system is no use for cherry-picking to stable. It won't apply. So we will need a commit with just the bug fix, then another 2 commits, one doing old db update, one doing new, and I will just cherry pick the old one. IE if something is needed for 3.10.x or 3.8.x it can't combine the db update part of the patch with the rest, for it to be able to apply. Chris
_______________________________________________ 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/
Chris,
Also, I have a correction to Chris's response: we will not need two separate sets of DB changes because I will be copying every non-linear update into updatedatabase.pl. That was the reason for the CheckVersion() routine.
Hi
While that is a good idea, and will mean the packages aren't totally busted on master. A commit that has both the old safe updatedatabase and the new system is no use for cherry-picking to stable. It won't apply. So we will need a commit with just the bug fix, then another 2 commits, one doing old db update, one doing new, and I will just cherry pick the old one.
IE if something is needed for 3.10.x or 3.8.x it can't combine the db update part of the patch with the rest, for it to be able to apply.
Sure it can. The DB update for 3.12+ will be a new file (which will be ignored by every version up until 3.12), every time. Any patches that make changes to the update system itself will have to be on different bugs, of course, but I was going to require that anyway. Regards, Jared -- Jared Camins-Esakov Bibliographer, C & P Bibliography Services, LLC (phone) +1 (917) 727-3445 (e-mail) jcamins@cpbibliography.com (web) http://www.cpbibliography.com/
Nope, that file won't exist in stable, and every patch that references it will fail to apply. I repeat I am not pushing anything to do with 7167 to stable . Including a file that we ignore. Chris Jared Camins-Esakov <jcamins@cpbibliography.com> wrote:
Chris,
Also, I have a correction to Chris's response: we will not need two separate sets of DB changes because I will be copying every non-linear update into updatedatabase.pl. That was the reason for the CheckVersion() routine.
Hi
While that is a good idea, and will mean the packages aren't totally busted on master. A commit that has both the old safe updatedatabase and the new system is no use for cherry-picking to stable. It won't apply. So we will need a commit with just the bug fix, then another 2 commits, one doing old db update, one doing new, and I will just cherry pick the old one.
IE if something is needed for 3.10.x or 3.8.x it can't combine the db update part of the patch with the rest, for it to be able to apply.
Sure it can. The DB update for 3.12+ will be a new file (which will be ignored by every version up until 3.12), every time. Any patches that make changes to the update system itself will have to be on different bugs, of course, but I was going to require that anyway.
Regards, Jared
-- Jared Camins-Esakov Bibliographer, C & P Bibliography Services, LLC (phone) +1 (917) 727-3445 (e-mail) jcamins@cpbibliography.com (web) http://www.cpbibliography.com/
------------------------------------------------------------------------
_______________________________________________ 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/
participants (5)
-
Chris Cormack -
Chris Cormack -
Jared Camins-Esakov -
Jonathan Druart -
Paul Poulain