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.git on 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/