6.0.0-git
2021-01-18

[#7240] Inconsistent sequence column names
Summary Inconsistent sequence column names
Queue Horde Base
Queue Version 3.2.1
Type Bug
State Resolved
Priority 3. High
Owners mrubinsk (at) horde (dot) org
Requester jan (at) horde (dot) org
Created 2008-08-26 (4528 days ago)
Due
Updated 2008-09-02 (4521 days ago)
Assigned 2008-09-02 (4521 days ago)
Resolved 2008-09-02 (4521 days ago)
Milestone 3.2.2
Patch No

History
2008-09-02 18:19:40 Michael Rubinsky Comment #6
State ⇒ Resolved
Reply to this comment
Fixed. Maybe even for real this time :)
2008-09-02 12:51:08 Jan Schneider Comment #5
State ⇒ Assigned
Reply to this comment
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.
2008-08-30 14:45:04 Michael Rubinsky Comment #4
State ⇒ Resolved
Reply to this comment
Resolved...and merged to FW_3.
2008-08-30 02:36:17 Chuck Hagenbuch Comment #3 Reply to this comment
I've run the upgrade on my production sites and things look good.
2008-08-29 19:42:40 Michael Rubinsky Comment #2
Taken from Jan Schneider
Taken from Chuck Hagenbuch
State ⇒ Feedback
Reply to this comment
Mostly done - would appreciate another set of eyes looking this over 
or testing before I merge to FW_3.




2008-08-26 13:16:22 Jan Schneider Comment #1
Type ⇒ Bug
State ⇒ Assigned
Priority ⇒ 3. High
Summary ⇒ Inconsistent sequence column names
Queue ⇒ Horde Base
Assigned to Chuck Hagenbuch
Assigned to Jan Schneider
Assigned to Michael Rubinsky
Milestone ⇒ 3.2.2
Patch ⇒ No
Reply to this comment
(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


Saved Queries