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 > > > > 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 > > > > > > 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 > > >> > > > >> 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 > 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 > > > > 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 > >> > > >> 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 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 > 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 >> 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 mailto: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 > > mailto: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 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 > > > 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 > 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 Monday, June 27, 2011 11:59 PM, Jeremy Orlow wrote: > On Thu, Jun 23, 2011 at 2:21 PM, Israel Hilerio 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
Re: [indexeddb] IDBRequest.transaction property set to null
On Thu, Jun 23, 2011 at 2:21 PM, Israel Hilerio 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
[indexeddb] IDBRequest.transaction property set to null
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. 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? Israel
