[Koha-devel] Update database changes proposal [IMPORTANT]

[Jonathan Druart]

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 at 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 at kohaaloha.com>
>
>>
>> On 2011-11-8, at 3:42 AM, MJ Ray wrote:
>>
>> > Paul Poulain <paul.poulain at 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 at 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 at bywatersolutions.com
> Twitter: @sekjal
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at 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/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20111112/dcbbbbc8/attachment.htm>