[Bug 11394] New: We should throw if continue() is called with a key <= the current position

http://www.w3.org/Bugs/Public/show_bug.cgi?id=11394

           Summary: We should throw if continue() is called with a key <=
                    the current position
           Product: WebAppsWG
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Indexed Database API
        AssignedTo: dave.null@w3.org
        ReportedBy: jonas@sicking.cc
         QAContact: member-webapi-cvs@w3.org
                CC: mike@w3.org, public-webapps@w3.org


(The below assumes a forward iterating cursor, opposite applies for a reverse
iterating cursor of course).

The spec currently states that when calling IDBCursor.continue and passing in a
key, the cursor moves to the first record which is greater than the current
position, and greater than or equal to the passed in key.

As we implemented this we realized that this makes the situation when someone
passes in a key which is less than or equal to the current position very
strange. The effect is that the key argument is ignored.

However most likely this was done in error. Worst case, the author might have
thought that the cursor would go back to the first entry whose key is greater
than or equal to the passed in key, ignoring the current position.

One example of buggy code would be displaying a sales-table with 10 entries
from every employee name. If the code ends up passing in a key which is less
than or equal to the passed in key, the code likely contains an error.

So a better behavior would be to throw if the passed in key is less than or
equal to the cursors current position. This makes it more clear that an error
occurred, as well as helps a debugger detect the exception and display the
current program state.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

Received on Tuesday, 23 November 2010 23:50:07 UTC