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

RE: [indexeddb] Behavior when calling IDBCursor.continue multiple times

From: Eliot Graff <Eliot.Graff@microsoft.com>
Date: Thu, 7 Jul 2011 22:32:12 +0000
To: Jeremy Orlow <jorlow@chromium.org>, Israel Hilerio <israelh@microsoft.com>
CC: "public-webapps@w3.org" <public-webapps@w3.org>
Message-ID: <CE3A5BFD1228D84A8D9C158EEC195FD53CC9A138@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com>
For both IDBCursor.continue and IDBCursorSync.continue, 

Added one paragraph to the description:
If you call this method multiple times, the cursor throws a NOT_ALLOWED_ERR exception and does not continue. If you catch the error you can then iterate through the cursor normally.

Standardized the wording in the async and sync NOT_ALLOWED_ERR description to be:
The cursor is currently being iterated, or has iterated past its end.

Eliot

From: public-webapps-request@w3.org [mailto:public-webapps-request@w3.org] On Behalf Of Jeremy Orlow
Sent: Monday, June 27, 2011 11:51 PM
To: Israel Hilerio
Cc: public-webapps@w3.org
Subject: Re: [indexeddb] Behavior when calling IDBCursor.continue multiple times

I thought it already was in there (or in some bug).  But, if not, yeah it should just be documented.
On Thu, Jun 23, 2011 at 2:32 PM, Israel Hilerio <israelh@microsoft.com> wrote:
We noticed that the spec doesn't say anything about what needs to happen if IDBCursor.continue is called multiple times.  We noticed that both FF and Chrome throw a NOT_ALLOWED_ERR exception.  If the exception is not caught, the cursor doesn't continue to iterate, an error event is triggered (errorCode = ABORT_ERR), and the transaction is aborted.  However, if the exception is caught, the cursor will iterate normally.  This model makes sense to us.
 
It seems this is something we should document on the spec.  Do you agree?
 
Israel
Received on Thursday, 7 July 2011 22:32:42 GMT

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