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 12:00 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Mon, Nov 1, 2010 at 4:49 AM, Jeremy Orlow <jorlow@chromium.org> wrote:
> >
> >
> > 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.
>
> I don't really agree that a counter is more elegant.


I said "doesn't seem particularly more elegant to me".  In other words, I
don't think it's enough more elegant that it's worth the additional API
surface area.


> It's also more
> complicated as you start iterating over the various cursors as you'll
> then have to wait for a different number of cursors depending on the
> values that you find.
>

I'm not really following you.  I guess in SQL terms you're talking about
left/outter joins?


>  > 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.
>
> Why is it not? Calling .continue() on another cursor is async.
>

I said "be necessary".  I'm pretty sure code composability _after returning
to the event loop_ is the only use case where a readyState would be
_necessary_.  I'd love to hear a concrete example of why someone might need
to do this.

As for it being convenient, I don't think think your example is that much
more convenient than other possible ways of doing it.  Have any developers
actually done something like this and found it painful?  Is there any code
you can point us to that would make the scenario more concrete and clear?
 If not, I think we should avoid adding surface area for something we don't
really understand very well.

J