Bug 60763 – IndexedDB chooses wrong record on PREV_NO_DUPLICATE index key cursor

• Status: RESOLVED
• Resolution: DUPLICATE
• Component: New Bugs

[Mark Pilgrim (Google)]

Original test: http://mxr.mozilla.org/mozilla2.0/source/dom/indexedDB/test/test_indexes.html?force=1

This is an adapation of part of a test from Mozilla's IndexedDB test suite. It creates an object store with several rows, creates indexes on each key, and iterates through an index key cursor from end to start using the PREV_NO_DUPLICATE flag. Of two records that contain the same key in the index, the cursor chooses the wrong one. Or, at least, a different one than Mozilla chooses.

In the attached test case, Joe and Pat have the same height. In an index key cursor on the 'height' key with a null key range, starting at the end and moving backward with PREV_NO_DUPLICATE, the test expects to find Joe, but WebKit finds Pat instead.

Similar to bug 60746, and I suspect the fix is similar (but in a different method, thus a separate bug report).

[Mark Pilgrim (Google)]

Created attachment 93442 [details]
test case

[Mark Pilgrim (Google)]

Created attachment 93904 [details]
Patch

[David Grogan]

Comment on attachment 93904 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=93904&action=review

> LayoutTests/storage/indexeddb/index-cursor.html:27
> +    "the BIGGEST string"

Why did these get changed?

[Adam Barth]

Who should review this change?

[Hans Wennborg]

This patch is old, and doesn't apply anymore since the SQLite back-end is gone, but it would be nice to get the test.

I'm not sure what the correct behavior is here. For PREV_NO_DUPLICATE, the spec says: "[...]  this cursor should yield all records, not including duplicates and its direction is monotonically decreasing order of keys. For every key with duplicate values, only the first record is yielded."

What does *first record* mean in this context? The first record that is found when traversing the records in monotonically decreasing order of keys, or the first record as in lowest record? This test seems to expect the latter, but we do the former.

[Hans Wennborg]

Oh, I see this is the same discussion as on Bug 60746.

It seems this was discussed here: http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/0480.html

[Joshua Bell]

Consensus on the list: http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/0599.html

Summary: PREV_NO_DUPLICATE should end up returning the same set of entries as NEXT_NO_DUPLICATE, just in reverse order. So PREV_NO_DUPLICATE should return the lowest (by primary key) of the duplicate entries.

[WebKit Review Bot]

Comment on attachment 93904 [details]
Patch

Rejecting attachment 93904 [details] from commit-queue.

Failed to run "['/mnt/git/webkit-commit-queue/Tools/Scripts/webkit-patch', '--status-host=queues.webkit.org', '-..." exit_code: 2

Last 500 characters of output:
fset -2 lines).
patching file LayoutTests/storage/indexeddb/index-cursor-expected.txt
patching file LayoutTests/storage/indexeddb/index-cursor.html
Hunk #1 succeeded at 15 (offset -2 lines).
patching file LayoutTests/storage/indexeddb/mozilla/index-key-prev-no-duplicate-expected.txt
patching file LayoutTests/storage/indexeddb/mozilla/index-key-prev-no-duplicate.html

Failed to run "[u'/mnt/git/webkit-commit-queue/Tools/Scripts/svn-apply', u'--reviewer', u'Darin Adler', u'--force']" exit_code: 1

Full output: http://queues.webkit.org/results/10996152

[Alec Flett]

the implementation is being done in another bug, both index and objectStore in the same plcae

*** This bug has been marked as a duplicate of bug 60746 ***