Re: [Bug 10430] New: [IndexedDB] We need to make it more clear IDBRequests can be reused and spec readyState's behavior

On Mon, Nov 1, 2010 at 11:08 AM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Mon, Nov 1, 2010 at 3:18 AM, Jeremy Orlow <jorlow@chromium.org> wrote:
> > On Mon, Nov 1, 2010 at 9:57 AM, Jonas Sicking <jonas@sicking.cc> wrote:
> >>
> >> On Mon, Nov 1, 2010 at 2:49 AM, Jeremy Orlow <jorlow@chromium.org>
> wrote:
> >> > On Mon, Nov 1, 2010 at 9:42 AM, Jonas Sicking <jonas@sicking.cc>
> wrote:
> >> >>
> >> >> On Mon, Nov 1, 2010 at 1:46 AM, Jeremy Orlow <jorlow@chromium.org>
> >> >> wrote:
> >> >> > Actually, what's the use case for readyState?  I can't think of any
> >> >> > uses
> >> >> > that we'd want to encourage.  Maybe we should just remove it.
> >> >>
> >> >> The use-case that I've heard in similar situations goes something
> like
> >> >> this:
> >> >>
> >> >> Code makes a request and at some point later hands the request to
> some
> >> >> other piece of code which is interested in the result.
> >> >> The other piece of code doesn't necessarily know if a result has been
> >> >> returned yet or not. Using readyState it can either simply get
> >> >> .result,
> >
> > Actually, this isn't possible.  As first proposed by Ben in "Changes to
> > IDBRequest and specification of the success and error events",
> > IDBRequest.result was moved just to the success event.  So there is no
> way
> > for something to access the result except through an onsuccess event
> > handler.  So the only use case for readyState is figuring out if you need
> to
> > re-issue a request.
>
> Good point, will have to think about that some more.
>
> >> or it can add a event listener for the "success" event and
> >> >> wait for the event to fire.
> >> >>
> >> >> I think that makes sense here too.
> >> >
> >> > What about the cursor case though?  Given that we're re-using the same
> >> > request object, I really don't think it makes much sense.
> >>
> >> It makes sense if the code the request is passed to is the one calling
> >> continue(), no?
> >
> > What's the use case for this though?  It seems awfully odd that a cursor
> > would be getting passed around after some async call after returning to
> the
> > event loop.  If you haven't returned to the event loop since your last
> call,
> > then there's no need to check ready state.  And things of course become
> very
> > confusing if you're issued multiple calls.
>
> Consider code that performs some type of merge for example. Placing
> several requests to different object stores and waiting for response
> from all of them.
>

So you're assuming that it'd set the same onsuccess handler for multiple
cursors and then check the ready state of them all upon each call and only
do processing when they're all ready?  If so, you can do this other ways
(use a counter or wait until you've gotten a call from each event.source you
expect), and this solution doesn't seem particularly more elegant to me.  If
not, I don't understand this use case.

Either way, I'm pretty sure this isn't an example of "a cursor would be
getting passed around after some async call after returning to the event
loop" which I believe is the only use case where ready state would actually
be necessary.


> > Which brings up the point: what's the behavior if you call .continue()
> > twice?  Will your on success fire twice?  What if the first result was
> null
> > (because you're out of results).  Should onsuccess fire twice with nulls
> or
> > only one null and ignore any subsequent continue() requests?
>
> I think that a call to .continue() on a cursor which still hasn't
> returned a result from the last call to continue() should result in a
> NOT_ALLOWED_ERR being thrown. There is just no logical way to honor
> two calls running at once, so I think the second call should either
> throw or do nothing.


Throw is much better than do nothing.  I think that's best for now, and we
can spec the behavior in the future if there's demand.  I'll file a bug.

You didn't respond to "Btw, if we do keep readyState around, we should
specify that its state changing should be done via the event loop to
maintain run to completion semantics."  Would you agree?

> P.S. I'm happy to discuss all of this f2f tomorrow rather than over email
> > now.
>
> Speaking of which, would be great to have an agenda. Some of the
> bigger items are:
>
> * Dynamic transactions
> * Arrays-as-keys
> * Arrays and indexes (what to do if the keyPath for an index evaluates
> to an array)
> * Synchronous API
>

I forked this into another thread.  Let's discuss there please.

J