Fixed. Maybe even for real this time :)

I just realized that the update scripts don't work. This has nothing 
to do with upgrading for example to Kronolith 2.2.1, because nothing 
changed in Kronolith. With the current scripts we require people to 
upgrade all applications if they want to upgrade to Horde 3.2.2, since 
the sequence name was only there.

Instead, we need a single script in Horde that checks for the share 
table names that we know of, checks if they exist, and updates them.

Resolved...and merged to FW_3.

I've run the upgrade on my production sites and things look good.

Mostly done - would appreciate another set of eyes looking this over 
or testing before I merge to FW_3.

(16:52:06) yunosh: we don't set the sequence field name when using mdb2

(16:52:10) yunosh: e.g. in shares

(16:52:59) yunosh: this will break any upgrade scripts in the future :(

(16:54:02) mrubinsk: not sure I follow... why can't we just use the default?

(16:54:21) yunosh: because mdb2 uses a different default than db

(16:54:37) yunosh: so all db tables have "id", all mdb2 tables "sequence"

(16:54:46) mrubinsk: yea...I remember a discussion about that when 
refactoring it

(16:54:48) yunosh: this makes automated updating impossible

(16:57:42) mrubinsk: automated updating to SQL shares you mean?

(16:58:12) yunosh: no, using mdb2_schema

(16:58:21) yunosh: when updating groupware

(16:58:32) yunosh: or the horde-db- scripts

(16:59:49) mrubinsk: hm.. ok

(17:00:39) yunosh: that's pretty bad, since we have both column names 
now on production servers

(17:07:16) mrubinsk: For things other than shares?

(17:07:39) mrubinsk: (SQL share required mdb2 before 3.2 went final, 
didn't it?)

(17:07:50) yunosh: i didn't check. do we use mdb2 anywhere else?

(17:07:58) yunosh: we didn't have sql shares before 3.2

(17:08:06) mrubinsk: correct

(17:08:20) mrubinsk: ...that's why I don't know why there would be old 
data in production

(17:08:30) yunosh: huh?

(17:09:03) yunosh: the point is that any horde 3.2 install has those 
two different column names in the sequence tables now

(17:09:10) mrubinsk: SQL shares required MDB2 when 3.2 was released  - 
so I don't see why we would have the "old" sequence tables in production

(17:09:33) yunosh: old == any DB driven table

(17:12:41) cjh: i'm still not sure i see the problem?

(17:13:45) yunosh: the problem is when it comes to upgrading

(17:14:01) mrubinsk: glad I'm not the only one :)

(17:14:13) yunosh: we have to tell mdb2_schema the sequence name, so 
that it can detect it when doing the upgrades

(17:14:46) mrubinsk: so it can't distinguish between different 
sequence tables then?

(17:14:58) yunosh: if the column of a sequence table doesn't match, it fails

(17:14:59) yunosh: yeah

(17:16:29) mrubinsk: ah, well that sucks

(17:17:02) cjh: do we tell it the sequence name for each table individually?

(17:18:06) yunosh: no, once in the factory. and we couldn't anyway, 
since it detects the db's tables itself

(17:22:59) cjh: i guess i'm not sure how this would have worked anyway 
- the DB:: sequence tables are sometimes different not just in terms 
of column names, if I remember

(17:23:33) yunosh: only different from db type to db type

(17:23:41) yunosh: but the same from DB to MDB2

(17:23:53) cjh: so it's just the column name?

(17:23:58) yunosh: yes

(17:24:06) cjh: could we patch mdb2_schema to accept either column name?

(17:24:24) cjh: or, we could have an upgrade script that doesn't use 
mdb2 schema that just makes all of them consistent i guess.

(17:36:04) yunosh: yeah, i don't see an alternative to making them consistent