| Summary | 2.1_to_2.2_sql_schema.php applies changes too broadly |
| Queue | Turba |
| Queue Version | 2.2-RC3 |
| Type | Bug |
| State | Resolved |
| Priority | 1. Low |
| Owners | mrubinsk (at) horde (dot) org |
| Requester | liamr (at) umich (dot) edu |
| Created | 02/22/2008 (6346 days ago) |
| Due | |
| Updated | 02/23/2008 (6345 days ago) |
| Assigned | |
| Resolved | 02/23/2008 (6345 days ago) |
| Github Issue Link | |
| Github Pull Request | |
| Milestone | |
| Patch | No |
Assigned to Michael Rubinsky
State ⇒ Resolved
Thanks!
State ⇒ Unconfirmed
Priority ⇒ 1. Low
Type ⇒ Bug
Summary ⇒ 2.1_to_2.2_sql_schema.php applies changes too broadly
Queue ⇒ Turba
New Attachment: 2.1_to_2.2_sql_schema.patch
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.