[horde] upgrading a *new* database doesn't look like it's going to work

[lst_hoe02 at kwsoft.de]

Zitat von "Robert P. J. Day" <rpjday at crashcourse.ca>:

>
>   looks like my carefully-designed plan for upgrading the horde
> database won't work.  i'm looking at the steps for 3.0.x->3.1.x, and
> the first step is fine:
>
>   # mysql ... blah blah ... db_name ... < 3.0_to_3.1.mysql.sql
>
> that appeared to work just fine since you have to *specify* the name
> of the database to affect.  (the end result appeared to be to just add
> the horde_histories table to the new database, is that correct?)
>
>   the second step, running "move_history_out_of_datatree.php", doesn't
> look like it's possible on my *new* database since i don't get to
> specify the name of the new database.  instead, i'm *guessing* that it
> has to be run from within the old horde installation, from which it
> will somehow pick up the old database name and affect only *that*
> (original) database.  is that correct?
>
>   perhaps i should just bite the bullet and upgrade the old database
> in place. it seems like that's going to be easier, if i understand
> what i'm reading properly.
>
> rday
>
> afterthought:  a couple suggestions.  if what i wrote above is
> correct, it might be worth extending the upgrade scripts to allow one
> to specify exactly which database to modify.  being able to do all
> that upgrading on a *copy* of the actual horde DB would seem to be a
> safe way to approach this.
>
> also, in the documentation, i think it would be *immensely* helpful
> to, after each command, describe the change that should have taken
> place so the user can verify it.
>
> for example, after i ran 3.0_to_3.1.mysql,sql, i got no feedback
> whatsoever, so i had no idea if it ran and worked, ran and failed or
> what.  it would have been useful for the docs to have said something
> like, "after that script runs, you can check that the database now has
> a new 'horde_histories' table."  that sort of sanity checking can
> really put a user's mind at ease.

My personal suggestion :
- Make a dump of your Horde database and import it to a new database
- Create a second Virtual Webhost with a copy of the old Horde installation
- Update the copy of Horde one Application by one starting with Horde  
by the following
        - Use new Horde and copy all additional Apps (IMP/Turba etc.) over
        - Alter the basic config files to match your previous settings
          DO NOT COPY THE OLD ONES IN PLACE, but copy the *.dist files  
and alter them.
        - Use the update scripts after checked that you have correct DB-Schema
        - Repeat for the Applications using Horde

With this you always have a working (old) installation and you can  
start from scratch if something fails horrible.
If you have finished you can exchange old/new Horde webroot and the  
old/new database. If you have working users at the old installation  
you must take it offline and repeat the steps for database  
update/migration-scripts on the old database to get the latest changes.

Regards

Andreas