Hi all ! I have already developed a new version of updatedatabase. It's not totally validated yet but in order to avoid parallels initiatives, let me explain you what I have already done. Work is on BibLibre git repository giit://git.biblibre.com/koha_biblibre.giton branch solr/ft/updatedb The goal was to have an interface to know status of different versions executed on a database. Requirements: on this branch, a precedent patch create a C4/Config/File/YAML.pm file. I use this module and you need an installdir section in your koha-conf.xml (<installdir>__INSTALL_BASE__</installdir>). How it works : 1 file per version (.pl ou .sql). if .sql, you could use comments, separator and query one after each others. if .pl please see skeleton.pl file. in admin/updatedatabase.pl, a table contains one line per version. For each line you can execute, see status (e.g. execution was ok or not (with errors)) or "force ok" (if you know theses queries don't need to be executed or have already been handled manually). You can't rollback a version. This tool only aim to have an interface showing status for each versions. Before execution, the routine C4::Update::Database::check_coherency check (for the most common queries) if the execution is coherent (if table or syspref already exists, etc.). You are welcome if you have any question or comment. Jonathan ps: I didn''t write Unit Tests :-/ 2011/11/10 Ian Walls <ian.walls@bywatersolutions.com>
I'd like to see the atomic update files continue to be perl, not SQL. SQL is often sufficient to do an update, but not always, particular if we're swapping out one implementation of a feature for a more generic one.
Also, I'd like to see 3 different subroutines/functions for each atomic update:
Check: Logic to see if the change is actually required: returns 0 or 1 Do: just like what have now, makes the change Undo: undoes the change to the database, allowing rollback to previous code states (this would be a new function)
-Ian
2011/11/9 Mason James <mtj@kohaaloha.com>
On 2011-11-8, at 3:42 AM, MJ Ray wrote:
Paul Poulain <paul.poulain@biblibre.com>
Let's say Limoges library has sponsored stuff that has resulted in atomicupdate/limogeupdate.pl [...] Does anyone see a problem with this new updatedatabase procedure ?
The only problem that I can see is that we should encourage updates to be .sql not .pl files.
oooh, great idea! i think this would simplify the proposed process even more
do other people agree?
_______________________________________________ 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/
-- Ian Walls Lead Development Specialist ByWater Solutions Phone # (888) 900-8944 http://bywatersolutions.com ian.walls@bywatersolutions.com Twitter: @sekjal
_______________________________________________ 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/