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

[Robert P. J. Day]

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.

  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?

  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.

  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.

  if there's no way around that, then i'll do it.  but it would have
been nice if that wasn't necessary.

rday

p.s.  the 3.1->3.2 mysql upgrade script appears capable of running
standalone as well.

--

========================================================================
Robert P. J. Day                               Waterloo, Ontario, CANADA

        Linux Consulting, Training and Annoying Kernel Pedantry.

Web page:                                          http://crashcourse.ca
Twitter:                                       http://twitter.com/rpjday
========================================================================