W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2010

[Bug 10400] New: [IndexedDB] IDBCursor.continue should return an IDBRequest

From: <bugzilla@jessica.w3.org>
Date: Thu, 19 Aug 2010 14:21:41 +0000
To: public-webapps@w3.org
Message-ID: <bug-10400-2927@http.www.w3.org/Bugs/Public/>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10400

           Summary: [IndexedDB] IDBCursor.continue should return an
                    IDBRequest
           Product: WebAppsWG
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Indexed Database API
        AssignedTo: andreip@google.com
        ReportedBy: jorlow@chromium.org
         QAContact: member-webapi-cvs@w3.org
                CC: mike@w3.org, public-webapps@w3.org


The IDL for IDBCursor.continue has it returning a boolean, but it's pretty
clear it's supposed to be returning an IDBRequest.  (The text for continue even
talks about firing a success events on the "returned object".)

It also says that result should be null in the case of hitting the end of the
range.  It doesn't specify what it should be in the case that it's not at the
end, though.  Returning the key or the value doesn't make any sense because the
key or value itself could be null (and thus there's no way to distinguish
between the end and a null key/value).  Returning null doesn't make sense
because you still can't distinguish.  The sync interface returns a bool to say
whether it's at the end of the range.  So it seems pretty clear to me that the
async variation should too "return" a bool through the success event.

-- 
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 Thursday, 19 August 2010 14:21:43 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:40 GMT