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

Yes, this should only impact the setVersion onsuccess handler and not the open onsuccess handler.  We're in agreement :-).  
I will work with Eliot to update the spec here.

Israel

On Friday, July 08, 2011 4:18 PM, Jonas Sicking wrote:
> I think setting the event.transaction to the newly created transaction for
> setVersion's success event makes sense (we might even do that in the firefox
> implementation iirc, but i'm not fully sure).
> 
> For all the other events mentioned in the original comment of this thread it
> needs to be null as no transaction is created.
> 
> This matches what is proposed, right?
> 
> / Jonas
> 
> On Fri, Jul 8, 2011 at 11:23 AM, Israel Hilerio <israelh@microsoft.com>
> wrote:
> > Jonas, what do you think?
> >
> >
> >
> > Israel
> >
> >
> >
> > On Wednesday, July 06, 2011 9:35 PM, Jeremy Orlow wrote:
> >
> > 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 Friday, 8 July 2011 23:52:21 UTC