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

Changes made and added to editor's draft. 

Edited the description of IDBRequest.transaction and step 10 of "VERSION_CHANGE transaction steps".

Thanks,

Eliot

> -----Original Message-----
> From: public-webapps-request@w3.org [mailto:public-webapps-
> request@w3.org] On Behalf Of Israel Hilerio
> Sent: Friday, July 08, 2011 4:52 PM
> To: Jonas Sicking
> Cc: public-webapps@w3.org; Victor Ngo; Jeremy Orlow
> Subject: 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 Thursday, 14 July 2011 19:24:47 UTC