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

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

From: Israel Hilerio <israelh@microsoft.com>
Date: Wed, 13 Jul 2011 01:25:03 +0000
To: Jonas Sicking <jonas@sicking.cc>
CC: Eliot Graff <Eliot.Graff@microsoft.com>, Jeremy Orlow <jorlow@chromium.org>, "public-webapps@w3.org" <public-webapps@w3.org>
Message-ID: <F695AF7AA77CC745A271AD0F61BBC61E3D1921A0@TK5EX14MBXC119.redmond.corp.microsoft.com>
I like what you wrote :-)


On Tuesday, July 12, 2011 5:18 PM, Jonas Sicking wrote:
> On Tue, Jul 12, 2011 at 4:55 PM, Israel Hilerio <israelh@microsoft.com> wrote:
> > I see what you're saying.
> >
> > What we originally wanted to convey was that calling this method
> consecutively or in a row within the same onsuccess handler is not
> allowed.  This assumed the success handler was not invoked in between these
> calls.
> > Would something similar to what I just wrote be enough to clarify the
> statement?
> It's not really related to it happening from the same onsuccess handler
> though, right? For example when creating joins you'll likely end up
> .continue'ing a cursor from the onsuccess handler of another cursor or a .get()
> request. When doing that you also need to be careful to not call continue
> before
> Maybe something like:
> "Calling .continue more than once before new cursor data has been loaded is
> not allowed and results in a NOT_ALLOWED_ERR exception being thrown. For
> example calling .continue twice from the same onsuccess handler results in a
> NOT_ALLOWED_ERR being thrown on the second call."
> But I'd definitely put it in a <p class=note> as to make sure that it's non-
> normative so that people don't misunderstand it to mean that
> NOT_ALLOWED_ERR is only thrown during the above mentioned condition.
> / Jonas
Received on Wednesday, 13 July 2011 01:25:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:22 UTC