[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>:

> On Wed, 26 Aug 2009, lst_hoe02 at kwsoft.de wrote:
>
>> 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
>
>   yes, i realize that that would work, but i was really hoping to not
> have to go through setting up every intermediate version of horde
> between 3.0.9 and 3.3.4.  mostly, what would make this easy (as long
> as i am correctly understanding those upgrade scripts) are upgrade
> scripts that can be run *completely* standalone, outside the context
> of any horde install.

You don't need every intermediate version of Horde, the most recent  
will be sufficient. You only have to apply all intermediate DB-schema  
changes if you don't create the DB from scratch. You even should be  
able to "cat" the schema scripts together and only use it once, but  
checking for the end result is always recommended.


>   consider the following:  someone used to have horde-3.0.9 running
> and has an old horde mysql database that's been gathering dust.
> suddenly, they want to start running horde and the current version is
> 3.3.4.  (sound familiar?)  so, how much work would it take to upgrade
> that database to be compatible and start using it?

-Apply all schema changes since 3.0. If you prepare in advance this  
will not even take a minute to actually apply.
- Now the trickier Part : You need a new working Horde version to run  
the update scripts. If your brave this can be done with a separate  
Webroot pointing to the same database ;-)

With this you have a starting point to upgrade all the rest of the  
apps with the Horde GUI and the update scripts from the apps  
(DB-Schema changes).

This is not something finished in a minute and should never be done on  
a bigger installation without testing.

>   what would be ideal would be upgrade scripts that can be run
> entirely standalone (if that's possible, maybe it isn't since i'm
> still learning this stuff).  the first upgrade script for 3.0->3.1 has
> that property -- you point it at a mysql database, and it does the
> first upgrade step.  and you can run it from anywhere.

There is work in progress with the Webmail Edition  
(http://www.horde.org/webmail/) but there are to many  
customizations/settings to get this automatically.

>
>   the second upgrade script for 3.0->3.1 (move history) does *not*
> have that property since it clearly(?) has to be run in the context of
> a horde install.  so this seems to suggest that i really do have to
> install every intermediate version of horde (or at least 3.1), do that
> upgrade, install the next version, etc, etc.  that's painful.

As said the update script should run fine with Horde 3.3.4
There are also scripts which you simply can skip. If you don't use  
"groups" at the moment there is no need to alter them.

Regards

Andreas