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

Re: [indexeddb] IDBRequest.transaction property set to null

From: Jeremy Orlow <jorlow@chromium.org>
Date: Wed, 6 Jul 2011 21:34:39 -0700
Message-ID: <CADBqD60wcvp0D1EmW9UQ+6cg0-DOYnH_uRh-o7e0JgjeSKJUJA@mail.gmail.com>
To: Israel Hilerio <israelh@microsoft.com>
Cc: "public-webapps@w3.org" <public-webapps@w3.org>, Victor Ngo <vicngo@microsoft.com>
I'd be OK with it.  Jonas, what do you think?

J

On Wed, Jul 6, 2011 at 10:27 AM, Israel Hilerio <israelh@microsoft.com>wrote:

> On Tuesday, June 28, 2011 11:21 AM, Israel Hilerio wrote:
> > On Monday, June 27, 2011 11:59 PM, Jeremy Orlow wrote:
> >
> > > On Thu, Jun 23, 2011 at 2:21 PM, Israel Hilerio <israelh@microsoft.com
> >
> > wrote:
> > >> In the definition of IDBRequest.transaction it stipulates that "This
> > >> property can be null for certain requests, such as for request
> returned from
> > IDBFactory.open and IDBDatabase.setVersion."  Based on this we understand
> > that the following handlers will set the transaction property to null:
> > >> * setVersion onsuccess handler
> > >> * setVersion onerror handler
> > >> * setVersion onblock handler
> > >> * open onsuccess handler
> > >> * open onerror handler
> > >> Are there any other times when this property should be set to null or
> is this
> > the complete list?  We couldn't think of any other times when this
> applied but
> > wanted to check.
> >
> > > I believe this is correct.
> >
> > >> Also, in the setVersion case, if we're setting the result property to
> its active
> > transaction, why are we setting the transaction property to null instead
> of the
> > same active transaction?
> >
> > > I know Jonas and I talked about this, but I don't remember the
> > > reasoning for sure.  One thing I can think of off the top of my head is
> that
> > it's weird that it'd start off null and then be set later.  Also, it
> would be
> > duplicate data given that .result is also set to the transaction.  Is
> there any
> > strong reason to set it?
> >
> > > J
> >
> > The main reason was to keep a consistent calling pattern inside our event
> > handlers:
> > * event.target.transaction.oncomplete
> >
> > The only exception to this pattern are the open and setVersion APIs.  In
> the
> > case of the setVersion handler we have to use:
> > * event.target.result.oncomplete
> >
> > It would be nice to use only one pattern all the time.
> >
> > Israel
> >
>
> What do you think about the idea of having a consistent/common access
> pattern for accessing the transaction inside most of our event handlers
> (i.e. inside setVersion but not open).  This will always guaranteed a good
> (not null) transaction handler developers can always count on.
>
> Israel
>
Received on Thursday, 7 July 2011 04:35:38 GMT

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