RE: [indexeddb] Behavior when calling IDBCursor.continue multiple times
Updated the spec with Jonas' wording. Thanks! Eliot -Original Message- From: Israel Hilerio Sent: Tuesday, July 12, 2011 6:25 PM To: Jonas Sicking Cc: Eliot Graff; Jeremy Orlow; public-webapps@w3.org Subject: RE: [indexeddb] Behavior when calling IDBCursor.continue multiple times I like what you wrote :-) Israel On Tuesday, July 12, 2011 5:18 PM, Jonas Sicking wrote: On Tue, Jul 12, 2011 at 4:55 PM, Israel Hilerio isra...@microsoft.com wrote: I see what you're saying. What we originally wanted to convey was that calling this method consecutively or in a row within the same onsuccess handler is not allowed. This assumed the success handler was not invoked in between these calls. Would something similar to what I just wrote be enough to clarify the statement? It's not really related to it happening from the same onsuccess handler though, right? For example when creating joins you'll likely end up .continue'ing a cursor from the onsuccess handler of another cursor or a .get() request. When doing that you also need to be careful to not call continue before Maybe something like: Calling .continue more than once before new cursor data has been loaded is not allowed and results in a NOT_ALLOWED_ERR exception being thrown. For example calling .continue twice from the same onsuccess handler results in a NOT_ALLOWED_ERR being thrown on the second call. But I'd definitely put it in a p class=note as to make sure that it's non- normative so that people don't misunderstand it to mean that NOT_ALLOWED_ERR is only thrown during the above mentioned condition. / Jonas
Re: [indexeddb] Behavior when calling IDBCursor.continue multiple times
Awesome! Thanks! Sorry again for jumping in so late. On Wed, Jul 13, 2011 at 2:25 PM, Eliot Graff eliot.gr...@microsoft.com wrote: Updated the spec with Jonas' wording. Thanks! Eliot -Original Message- From: Israel Hilerio Sent: Tuesday, July 12, 2011 6:25 PM To: Jonas Sicking Cc: Eliot Graff; Jeremy Orlow; public-webapps@w3.org Subject: RE: [indexeddb] Behavior when calling IDBCursor.continue multiple times I like what you wrote :-) Israel On Tuesday, July 12, 2011 5:18 PM, Jonas Sicking wrote: On Tue, Jul 12, 2011 at 4:55 PM, Israel Hilerio isra...@microsoft.com wrote: I see what you're saying. What we originally wanted to convey was that calling this method consecutively or in a row within the same onsuccess handler is not allowed. This assumed the success handler was not invoked in between these calls. Would something similar to what I just wrote be enough to clarify the statement? It's not really related to it happening from the same onsuccess handler though, right? For example when creating joins you'll likely end up .continue'ing a cursor from the onsuccess handler of another cursor or a .get() request. When doing that you also need to be careful to not call continue before Maybe something like: Calling .continue more than once before new cursor data has been loaded is not allowed and results in a NOT_ALLOWED_ERR exception being thrown. For example calling .continue twice from the same onsuccess handler results in a NOT_ALLOWED_ERR being thrown on the second call. But I'd definitely put it in a p class=note as to make sure that it's non- normative so that people don't misunderstand it to mean that NOT_ALLOWED_ERR is only thrown during the above mentioned condition. / Jonas
RE: [indexeddb] Behavior when calling IDBCursor.continue multiple times
I see what you're saying. What we originally wanted to convey was that calling this method consecutively or in a row within the same onsuccess handler is not allowed. This assumed the success handler was not invoked in between these calls. Would something similar to what I just wrote be enough to clarify the statement? Israel On Monday, July 11, 2011 9:24 PM, Jonas Sicking wrote: Hmm.. The fix here is somewhat unclear. Obviously you're allowed to call .continue multiple times if a success event fires in between. The very first sentence in the definition for .continue reads: If this cursor's got value flag is false, this method throws a NOT_ALLOWED_ERR. Was this not enough? I'd be fine with keeping the current sentence, but it would need to be clarified to make it clear that .continue() can be called multiple times if success fires in between, and that success event doesn't represent reaching the end of the cursor. Or something to that extent. / Jonas On Thu, Jul 7, 2011 at 3:32 PM, Eliot Graff eliot.gr...@microsoft.com wrote: For both IDBCursor.continue and IDBCursorSync.continue, Added one paragraph to the description: If you call this method multiple times, the cursor throws a NOT_ALLOWED_ERR exception and does not continue. If you catch the error you can then iterate through the cursor normally. Standardized the wording in the async and sync NOT_ALLOWED_ERR description to be: The cursor is currently being iterated, or has iterated past its end. Eliot From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Jeremy Orlow Sent: Monday, June 27, 2011 11:51 PM To: Israel Hilerio Cc: public-webapps@w3.org Subject: Re: [indexeddb] Behavior when calling IDBCursor.continue multiple times I thought it already was in there (or in some bug). But, if not, yeah it should just be documented. On Thu, Jun 23, 2011 at 2:32 PM, Israel Hilerio isra...@microsoft.com wrote: We noticed that the spec doesn't say anything about what needs to happen if IDBCursor.continue is called multiple times. We noticed that both FF and Chrome throw a NOT_ALLOWED_ERR exception. If the exception is not caught, the cursor doesn't continue to iterate, an error event is triggered (errorCode = ABORT_ERR), and the transaction is aborted. However, if the exception is caught, the cursor will iterate normally. This model makes sense to us. It seems this is something we should document on the spec. Do you agree? Israel
Re: [indexeddb] Behavior when calling IDBCursor.continue multiple times
On Tue, Jul 12, 2011 at 4:55 PM, Israel Hilerio isra...@microsoft.com wrote: I see what you're saying. What we originally wanted to convey was that calling this method consecutively or in a row within the same onsuccess handler is not allowed. This assumed the success handler was not invoked in between these calls. Would something similar to what I just wrote be enough to clarify the statement? It's not really related to it happening from the same onsuccess handler though, right? For example when creating joins you'll likely end up .continue'ing a cursor from the onsuccess handler of another cursor or a .get() request. When doing that you also need to be careful to not call continue before Maybe something like: Calling .continue more than once before new cursor data has been loaded is not allowed and results in a NOT_ALLOWED_ERR exception being thrown. For example calling .continue twice from the same onsuccess handler results in a NOT_ALLOWED_ERR being thrown on the second call. But I'd definitely put it in a p class=note as to make sure that it's non-normative so that people don't misunderstand it to mean that NOT_ALLOWED_ERR is only thrown during the above mentioned condition. / Jonas
RE: [indexeddb] Behavior when calling IDBCursor.continue multiple times
I like what you wrote :-) Israel On Tuesday, July 12, 2011 5:18 PM, Jonas Sicking wrote: On Tue, Jul 12, 2011 at 4:55 PM, Israel Hilerio isra...@microsoft.com wrote: I see what you're saying. What we originally wanted to convey was that calling this method consecutively or in a row within the same onsuccess handler is not allowed. This assumed the success handler was not invoked in between these calls. Would something similar to what I just wrote be enough to clarify the statement? It's not really related to it happening from the same onsuccess handler though, right? For example when creating joins you'll likely end up .continue'ing a cursor from the onsuccess handler of another cursor or a .get() request. When doing that you also need to be careful to not call continue before Maybe something like: Calling .continue more than once before new cursor data has been loaded is not allowed and results in a NOT_ALLOWED_ERR exception being thrown. For example calling .continue twice from the same onsuccess handler results in a NOT_ALLOWED_ERR being thrown on the second call. But I'd definitely put it in a p class=note as to make sure that it's non- normative so that people don't misunderstand it to mean that NOT_ALLOWED_ERR is only thrown during the above mentioned condition. / Jonas
Re: [indexeddb] Behavior when calling IDBCursor.continue multiple times
Hmm.. The fix here is somewhat unclear. Obviously you're allowed to call .continue multiple times if a success event fires in between. The very first sentence in the definition for .continue reads: If this cursor's got value flag is false, this method throws a NOT_ALLOWED_ERR. Was this not enough? I'd be fine with keeping the current sentence, but it would need to be clarified to make it clear that .continue() can be called multiple times if success fires in between, and that success event doesn't represent reaching the end of the cursor. Or something to that extent. / Jonas On Thu, Jul 7, 2011 at 3:32 PM, Eliot Graff eliot.gr...@microsoft.com wrote: For both IDBCursor.continue and IDBCursorSync.continue, Added one paragraph to the description: If you call this method multiple times, the cursor throws a NOT_ALLOWED_ERR exception and does not continue. If you catch the error you can then iterate through the cursor normally. Standardized the wording in the async and sync NOT_ALLOWED_ERR description to be: The cursor is currently being iterated, or has iterated past its end. Eliot From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Jeremy Orlow Sent: Monday, June 27, 2011 11:51 PM To: Israel Hilerio Cc: public-webapps@w3.org Subject: Re: [indexeddb] Behavior when calling IDBCursor.continue multiple times I thought it already was in there (or in some bug). But, if not, yeah it should just be documented. On Thu, Jun 23, 2011 at 2:32 PM, Israel Hilerio isra...@microsoft.com wrote: We noticed that the spec doesn't say anything about what needs to happen if IDBCursor.continue is called multiple times. We noticed that both FF and Chrome throw a NOT_ALLOWED_ERR exception. If the exception is not caught, the cursor doesn't continue to iterate, an error event is triggered (errorCode = ABORT_ERR), and the transaction is aborted. However, if the exception is caught, the cursor will iterate normally. This model makes sense to us. It seems this is something we should document on the spec. Do you agree? Israel
RE: [indexeddb] Behavior when calling IDBCursor.continue multiple times
For both IDBCursor.continue and IDBCursorSync.continue, Added one paragraph to the description: If you call this method multiple times, the cursor throws a NOT_ALLOWED_ERR exception and does not continue. If you catch the error you can then iterate through the cursor normally. Standardized the wording in the async and sync NOT_ALLOWED_ERR description to be: The cursor is currently being iterated, or has iterated past its end. Eliot From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Jeremy Orlow Sent: Monday, June 27, 2011 11:51 PM To: Israel Hilerio Cc: public-webapps@w3.org Subject: Re: [indexeddb] Behavior when calling IDBCursor.continue multiple times I thought it already was in there (or in some bug). But, if not, yeah it should just be documented. On Thu, Jun 23, 2011 at 2:32 PM, Israel Hilerio isra...@microsoft.com wrote: We noticed that the spec doesn't say anything about what needs to happen if IDBCursor.continue is called multiple times. We noticed that both FF and Chrome throw a NOT_ALLOWED_ERR exception. If the exception is not caught, the cursor doesn't continue to iterate, an error event is triggered (errorCode = ABORT_ERR), and the transaction is aborted. However, if the exception is caught, the cursor will iterate normally. This model makes sense to us. It seems this is something we should document on the spec. Do you agree? Israel
Re: [indexeddb] Behavior when calling IDBCursor.continue multiple times
I thought it already was in there (or in some bug). But, if not, yeah it should just be documented. On Thu, Jun 23, 2011 at 2:32 PM, Israel Hilerio isra...@microsoft.comwrote: We noticed that the spec doesn’t say anything about what needs to happen if IDBCursor.continue is called multiple times. We noticed that both FF and Chrome throw a NOT_ALLOWED_ERR exception. If the exception is not caught, the cursor doesn’t continue to iterate, an error event is triggered (errorCode = ABORT_ERR), and the transaction is aborted. However, if the exception is caught, the cursor will iterate normally. This model makes sense to us. ** ** It seems this is something we should document on the spec. Do you agree?* *** ** ** Israel
