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-requ...@w3.org [mailto:public-webapps- requ...@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 isra...@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 isra...@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 isra...@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
RE: [indexeddb] IDBRequest.transaction property set to null
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 isra...@microsoft.commailto:isra...@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 isra...@microsoft.commailto:isra...@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
Re: [indexeddb] IDBRequest.transaction property set to null
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 isra...@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 isra...@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 isra...@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
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 isra...@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 isra...@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 isra...@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
RE: [indexeddb] IDBRequest.transaction property set to null
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 isra...@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
Re: [indexeddb] IDBRequest.transaction property set to null
I'd be OK with it. Jonas, what do you think? J On Wed, Jul 6, 2011 at 10:27 AM, Israel Hilerio isra...@microsoft.comwrote: 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 isra...@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
Re: [indexeddb] IDBRequest.transaction property set to null
On Thu, Jun 23, 2011 at 2:21 PM, Israel Hilerio isra...@microsoft.comwrote: 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
RE: [indexeddb] IDBRequest.transaction property set to null
On Monday, June 27, 2011 11:59 PM, Jeremy Orlow wrote: On Thu, Jun 23, 2011 at 2:21 PM, Israel Hilerio isra...@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
