- From: Israel Hilerio <israelh@microsoft.com>
- Date: Fri, 8 Jul 2011 23:51:40 +0000
- To: Jonas Sicking <jonas@sicking.cc>
- CC: "public-webapps@w3.org" <public-webapps@w3.org>, Victor Ngo <vicngo@microsoft.com>, Jeremy Orlow <jorlow@chromium.org>
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