- From: Jonas Sicking <jonas@sicking.cc>
- Date: Fri, 8 Jul 2011 16:18:07 -0700
- To: Israel Hilerio <israelh@microsoft.com>
- Cc: "public-webapps@w3.org" <public-webapps@w3.org>, Victor Ngo <vicngo@microsoft.com>, Jeremy Orlow <jorlow@chromium.org>
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:19:04 UTC