Bug 128444 - IDB: storage/indexeddb/mozilla/index-prev-no-duplicate.html fails
Summary: IDB: storage/indexeddb/mozilla/index-prev-no-duplicate.html fails
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit2 (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Brady Eidson
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2014-02-07 22:33 PST by Brady Eidson
Modified: 2014-02-08 22:05 PST (History)
1 user (show)

See Also:


Attachments
Patch v1 (10.38 KB, patch)
2014-02-08 16:41 PST, Brady Eidson
mitz: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Brady Eidson 2014-02-07 22:33:03 PST
IDB: storage/indexeddb/mozilla/index-prev-no-duplicate.html fails

- The index cursor statements weren't doing secondary ordering by value.
- Something else I haven't identified yet.
Comment 1 Radar WebKit Bug Importer 2014-02-07 22:33:17 PST
<rdar://problem/16018914>
Comment 2 Brady Eidson 2014-02-07 22:34:08 PST
Have that first part fixed already.  Will fix the second part in the A.M.
Comment 3 Radar WebKit Bug Importer 2014-02-07 22:35:22 PST
<rdar://problem/16018918>
Comment 4 Brady Eidson 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.
Comment 5 Brady Eidson 2014-02-08 16:41:29 PST
Created attachment 223595 [details]
Patch v1
Comment 6 mitz 2014-02-08 21:54:37 PST
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?
Comment 7 Brady Eidson 2014-02-08 22:05:20 PST
http://trac.webkit.org/changeset/163741