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

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

From: Israel Hilerio <israelh@microsoft.com>
Date: Fri, 8 Jul 2011 18:23:41 +0000
To: "Jonas Sicking (jonas@sicking.cc)" <jonas@sicking.cc>
CC: "public-webapps@w3.org" <public-webapps@w3.org>, Victor Ngo <vicngo@microsoft.com>, Jeremy Orlow <jorlow@chromium.org>
Message-ID: <F695AF7AA77CC745A271AD0F61BBC61E3D18D295@TK5EX14MBXC119.redmond.corp.microsoft.com>
Jonas, what do you think?


On Wednesday, July 06, 2011 9:35 PM, Jeremy Orlow wrote:
I'd be OK with it.  Jonas, what do you think?

On Wed, Jul 6, 2011 at 10:27 AM, Israel Hilerio <israelh@microsoft.com<mailto: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<mailto: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.

Received on Friday, 8 July 2011 18:24:12 UTC

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