[Webkit-unassigned] [Bug 128444] IDB: storage/indexeddb/mozilla/index-prev-no-duplicate.html fails
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Sat Feb 8 10:07:24 PST 2014
https://bugs.webkit.org/show_bug.cgi?id=128444
--- Comment #4 from Brady Eidson <beidson at apple.com> 2014-02-08 10:04:41 PST ---
(In reply to comment #0)
> IDB: storage/indexeddb/mozilla/index-prev-no-duplicate.html fails
...
> - Something else I haven't identified yet.
So say you're walking an index cursor and you get to a lump of 4 record in a row that have the same key.
Those four values are sorted by their referenced value.
In the test case, we see these records in the object store:
{ key: "237-23-7736", value: { name: "Joe", height: 65, weight: 150 } },
{ key: "237-23-7737", value: { name: "Pat", height: 65, weight: 100 } },
{ key: "237-23-7738", value: { name: "Leo", height: 65, weight: 180 } },
{ key: "237-23-7739", value: { name: "Jef", height: 65, weight: 120 } },
The 'height' index has the entries:
{ key: 65, value: "237-23-7736" },
{ key: 65, value: "237-23-7737" },
{ key: 65, value: "237-23-7738" },
{ key: 65, value: "237-23-7739" },
So when walking the index backwards, you're supposed to first see the record or 7739, then 7738, then 7737, then 7736.
But when walking the index backwards *uniquely*, you're only supposed to see one of the 65 entries. Which one?
Well, since you get to the 7739 record first (when walking backwards...) I thought it was the 7739 record.
But it turns out when picking which record to return for a unique cursor, you walk to the last record that matches - in this case, the 7736 record.
Yikes.
A new flavor of index cursor statement will fix this.
--
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
More information about the webkit-unassigned
mailing list