[Tickets #6207] Collection of upgrade scripts

bugs at horde.org bugs at horde.org
Tue Feb 5 00:17:44 UTC 2008


DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/?id=6207
-----------------------------------------------------------------------
 Ticket             | 6207
 Created By         | difosfor at gmail.com
 Summary            | Collection of upgrade scripts
 Queue              | Horde Base
 Version            | 3.1.3
 Type               | Enhancement
 State              | New
 Priority           | 1. Low
 Milestone          | 
 Patch              | 
 Owners             | 
+New Attachment     | horde-upgrade.zip
-----------------------------------------------------------------------


difosfor at gmail.com (2008-02-04 19:17) wrote:

This is a collection of horde upgrade scripts I made to upgrade from a
customized CVS checkout of Horde 3.0 to the current debian horde version
3.1.3.

I'm afraid these aren't ready to be included in the scripts directory
straight away, but I feel they can be interesting to other people working
on upgrading Horde. Perhaps they can be included in a contrib directory or
something?

Some notes:
* Sorry, these scripts were meant for one time use so their not superbly
engineered or commented.
* Contrary to most other scripts these don't depend on Horde being
installed on the localhost, they only need a connection to Horde's
database. 
* copy_and_adapt_horde_3.0_to_3.1.sh is the base script which calls the
other scripts to help copy and adapt the 3.0 database to a new 3.1 database
for use by the new installation of Horde
* move_history_from_datatree.php is the only script which is not
customized at all to our particular installation, but the other files can
be easily adapted to your situation.
* A few files have been stripped of some of the information for privacy
reasons

Answers to some questions bound to be asked:
* Why didn't you just use the Horde API?
I couldn't find good documentation of the Horde API and found it easier to
just reverse engineer its database usage. Furthermore I wanted to execute
the scripts from another host for practical reasons.
* Why didn't you just use the existing upgrade scripts?
Database data model changes weren't properly reflected in the SQL upgrade
scripts.
move_history_out_of_datatree.php was extremely slow and didn't work
properly (I could not find back some email history entries).
migrate_user_categories.php didn't convert numeric category values to the
new text category name values.
public_to_horde_share.php didn't work for me (sorry, forgot why exactly).


PS: I can't wait for automatic upgrade functionality in Horde. At the very
least any data model changes should be automatically handled IMHO.



More information about the bugs mailing list