Summary: | IDB: storage/indexeddb/mozilla/index-prev-no-duplicate.html fails | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Brady Eidson <beidson> | ||||
Component: | WebKit2 | Assignee: | Brady Eidson <beidson> | ||||
Status: | RESOLVED FIXED | ||||||
Severity: | Normal | CC: | webkit-bug-importer | ||||
Priority: | P2 | Keywords: | InRadar | ||||
Version: | 528+ (Nightly build) | ||||||
Hardware: | All | ||||||
OS: | All | ||||||
Attachments: |
|
Description
Brady Eidson
2014-02-07 22:33:03 PST
Have that first part fixed already. Will fix the second part in the A.M. (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. Created attachment 223595 [details]
Patch v1
Comment on attachment 223595 [details] Patch v1 View in context: https://bugs.webkit.org/attachment.cgi?id=223595&action=review > Source/WebKit2/DatabaseProcess/IndexedDB/sqlite/SQLiteIDBCursor.cpp:75 > indexStatements.reserveCapacity(8); Seems like we need to bump this 8 up? Isn’t there a more efficient reserveInitialCapacity? |