[horde] H3 to H5 upgrade - some database structure differences

[Jan Schneider]

Zitat von Geoff Roberts <geoff at apro.com.au>:

> Hi,
>
> I'm testing an upgrade from Horde 3 to Horde 5.
>
> Read the UPGRADING and INSTALL notes.
>
> After upgrading I found some differences between the upgraded Horde  
> 3 database
> and a vanilla Horde 5 database.
>
> Just wanted to check if these are expected with someone in the know...
>
> 1. Some potential items not adjusted
>
> a) in horde_signups
> signup_date was left as varchar(255) and not converted to int(11)
>
> Looking at the code in Horde 5, it assumes Unix epoch time (hence  
> the int(11))
> so this difference could cause grief.

For some reason this was a varchar field only in the mysql-specific  
script in H3. No idea why. We should probably convert that. Please  
create a bug report.

> b) in horde_alarms
> Horde 5 has a new 'id' column which is an autoincrement
> This was not created in the upgraded Horde 3 database.

That column shouldn't be there, but doesn't do any harm either. It's  
unused. Please create a bug report.

> Other differences when between Horde 3 upgraded and vanilla Horde 5  
> - would any
> of these make any difference?
>
> a) A few longblob not converted to blob
> b) A few bigint not converted to int
> c) A few varchar(250 or 200) not converted to varchar(255)
> d) Some tinyint not converted to smallint
> e) A tinyint not converted to int
> f) A whole range of indexes were not renamed - eg in horde_alarms
>   KEY `alarm_id_idx` (`alarm_id`) was not renamed to   KEY
> `index_horde_alarms_on_alarm_id` (`alarm_id`)

Those are MySQL special cases from MySQL-specific scripts in H3. Those  
are no longer used with the new, more portable database and migration  
abstraction in H5. Some of those are even left-over limitations of  
older MySQL versions.
They can safely be ignored, though there is some remote chance that we  
might try to delete indexes by their name in future migrations.
-- 
Jan Schneider
The Horde Project
http://www.horde.org/