[Tickets #6308] 2.1_to_2.2_sql_schema.php applies changes too broadly
bugs at horde.org
bugs at horde.org
Fri Feb 22 22:06:51 UTC 2008
DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.
Ticket URL: http://bugs.horde.org/ticket/?id=6308
-----------------------------------------------------------------------
Ticket | 6308
Created By | liamr at umich.edu
Summary | 2.1_to_2.2_sql_schema.php applies changes too broadly
Queue | Turba
Version | 2.2-RC3
Type | Bug
State | Unconfirmed
Priority | 1. Low
Milestone |
Patch |
Owners |
+New Attachment | 2.1_to_2.2_sql_schema.patch
-----------------------------------------------------------------------
liamr at umich.edu (2008-02-22 17:06) wrote:
This is related to this thread..
http://marc.info/?l=turba&m=120179329503586&w=2
2.1_to_2.2_sql_schema.php isn't specific enough when it mangles the data,
converting from the 2.1 scheme to the 2.2 schema.
Consider the following situation..
user A has an addressbook entry for "John Smith". The script issues...
UPDATE turba_objects SET object_firstname =
'John', object_lastname = 'Smith' WHERE object_lastname = 'John Smith'
user B has an addressbook entry for "Smith" (No firstname, just "Smith").
The script issues
UPDATE turba_objects SET object_firstname =
'', object_lastname = 'Smith' WHERE object_lastname = 'Smith'
if User B's entry is converted after User A's entry, User A's entry also
has it's firstname set to ''. It's reset object_firstname for *any* entry
with object_lastname = "Smith" that has already been converted. This is
super bad.
A similar flaw exists with the address entries.
So... I've altered the SQL to take object_id into account.. which
guaranties that we're updating the record we think we're updating. It also
has the added bonus of speeding the script up (since we're using the
table's primary key). Our turba_objects table has 1.5 million entries.
The original script took over five days to complete. The updated script
takes about an hour.
More information about the bugs
mailing list