Closed (fixed)
Project:
Location
Version:
5.x-3.0-rc2
Component:
Code
Priority:
Critical
Category:
Bug report
Assigned:
Reporter:
Created:
3 Dec 2008 at 15:45 UTC
Updated:
24 May 2009 at 05:17 UTC
Found a small error with potentially large ramifications while setting up a site. While retrieving the db_next_id() for location_lid, the table expansion is missing, which causes it to be ignored if it is utilized.
output from diff on how I eliminated the issue:
1527c1527,1528
< $location['lid'] = db_next_id('location_lid');
---
> // altered this line to fix compatibility with drupal table name expansion
> $location['lid'] = db_next_id('{location}_lid');
Comments
Comment #1
acappellamaniac commentedThis is quite important to be fixed in an official release because it already messed up my location entries ......
Volker
Comment #2
bdragon commentedGeez, you're right, it's been broken since March.
Investigating.
Comment #3
bdragon commentedFixed in http://drupal.org/cvs?commit=157939
I also made an update routine, I would like verification that it's actually sane.
I left postgresql unimplemented on purpose, because A) I determined that the bug would have caused errors during normal operation if someone was using a prefixed location table in postgresql, and I don't have any record of anyone reporting this, and B) I tried to write one but then realized that sequences are explicit in postgresql anyway and this would need to be examined by a human.
Comment #4
EvanDonovan commentedIs there a way to fix this problem after it has already affected your data? Or is the only option to restore from a backup?
Comment #5
EvanDonovan commentedHere's how our database administrator fixed the corrupted data in our database:
1) Found all location_instance records with duplicated location ids (>5200 pairs).
2) Made the assumption that the record pointing to a higher node id was the newer one
3) Gave all these new records and their associated Location, location phone, and location fax records an lid = lid +100,000
4) Copied the location, phone, and fax records from drupal_11/1 into the production data base
5) Renumbered the “new” location_instance records’ lid sequentially starting a bit above the value on the sequences table along with their location, fax, and phone records
6) Checked a bit
7) Incremented the sequence value based on last record renumbered.
Comment #6
yesct commentedbdragon, I'm tempted to mark this fixed. :) Should I mark it needs review to get someone to look at it?
Comment #7
yesct commentedalthough I think maintainer needs more info is just as good. just need a person to look at it. :)
Comment #8
yesct commentedEvanDonovan, Marking this closed since no response. Please reply if still an issue for you, or open a new issue (and link to this one) on how to fix data already messed up by this.