- From: Israel Hilerio <israelh@microsoft.com>
- Date: Tue, 28 Jun 2011 18:21:09 +0000
- To: Jeremy Orlow <jorlow@chromium.org>
- CC: "public-webapps@w3.org" <public-webapps@w3.org>
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
Received on Tuesday, 28 June 2011 18:21:38 UTC