Re: [Koha-devel] Database Structure [update strategy : proposal]

[Paul POULAIN]

MJ Ray a écrit :
> Paul POULAIN <address@hidden> wrote:
> > Let me know what you think of this (during the chat or on the list)
> Key points from this email:
> > what is interesting with that behaviour is that you just have to install 
> > a new version, and the librarian will automatically be redirected to the 
> > update page before login, and see what has been done. [...]
>
> This should be possible by comparing the version stored in the
> database with the $C4::Context::VERSION value, however it happens.

that's how it works atm.

> > After that, kohastructure.sql is the authoritative file for 3.0 structure
> > kohastructure.sql + updatedatabase applied is the authoritative 
> > structure for 3.X version.
>
> That would mean a new developer starting at release 3.X could not
> check kohastructure.sql to see the database layout.  I seem to recall
> that I struggled with 2.0 until you sent me a working koha.sql file.
> I was also asking back then "why updatedatabase instead of SQL?" and
> didn't get a clear answer:

You're right, but we want :
- to have a single authoritative file
- "automatic" updates

From 2 pick 1 i'm afraid : if we have a single authoritative SQL file, 
then we can't have an updatedatabase. If we have an updatedatabase and 
an authoritative SQL file, then we have 2 authoritative places.

the alternative could be to have kohastructure.30.sql, then 
3.00.00.001.sql, 3.00.00.002.sql, ... and apply all of them.

But we would not have a single entry point.
And that would let open the question of having a non SQL-only update.

With nested SQL queries, we can do very interesting & powerfull things, 
so I agree that we could never need to do Perl hacking.


> I strongly feel that this should be done with a sequence of SQL files,
> each one updating X.Y.Z.T to X.Y.Z.T+1 - one version at a time.  These
> could be loaded by the webinstaller with similar routines to the
> current data files.  Seems easier and more portable than calling
> system() on another script to me.

In fact it's what is done now, except the SQL is embeeded in the 
updatedatabase script. If you want to move them outside & load 
updates/*.sql files, I won't object (except that the load must be 
ordered, so we will have to check carefully what we do)

> Looking at the 3.0 series changes in updatedatabase, the only thing
> that isn't possible is DropAllForeignKeys - but why is that there?
> We should know what foreign keys we were using and DROP them one by one.
> If we run DropAllForeignKeys on a table, we will also DROP any foreign
> keys installed by a contrib.

You're probably right, I can't remember why I did that.

> paul, hdl and ryan (+ anyone else?) all made the point that one day,
> we may want to make a change that isn't possible with SQL alone.  That
> raises a few questions:
>
> - are such fundamental changes a good idea without a version update?

++

> - should we use perl-calculated updates every time, or only as a last
> resort?

I think if we go SQL, we can't mix, unless doing complex (and probably 
ugly) things)

--
Paul POULAIN et Henri Damien LAURENT
Consultants indépendants en logiciels libres et bibliothéconomie 
(http://www.koha-fr.org)
Tel : 04 91 31 45 19