- From: Israel Hilerio <israelh@microsoft.com>
- Date: Wed, 6 Jul 2011 17:27:23 +0000
- To: Jeremy Orlow <jorlow@chromium.org>
- CC: "public-webapps@w3.org" <public-webapps@w3.org>, Victor Ngo <vicngo@microsoft.com>
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 Wednesday, 6 July 2011 17:27:53 UTC