Re: [Bug 10430] New: [IndexedDB] We need to make it more clear IDBRequests can be reused and spec readyState's behavior
On Mon, Nov 1, 2010 at 3:17 PM, Shawn Wilsher sdwi...@mozilla.com wrote: On 11/1/2010 5:29 AM, Jeremy Orlow wrote: If not, I think we should avoid adding surface area for something we don't really understand very well. I agree with this. Less is better at this point I think (when appropriate, of course). Of course, the question is where it's appropriate. The reason I prefer to keep readyState is that I've seen things move that way elsewhere. We've recently added it to Document, HTMLMediaElement, EventSource and WebSocket. I do agree that as long as the result isn't on IDBRequest then it doesn't make much sense since if you get a reference to a IDBRequest with readyState=DONE you can't get to the result anyway. / Jonas
Re: [Bug 10430] New: [IndexedDB] We need to make it more clear IDBRequests can be reused and spec readyState's behavior
On Thu, Nov 4, 2010 at 3:36 PM, Jeremy Orlow jor...@chromium.org wrote: On Thu, Nov 4, 2010 at 12:35 PM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Nov 1, 2010 at 3:17 PM, Shawn Wilsher sdwi...@mozilla.com wrote: On 11/1/2010 5:29 AM, Jeremy Orlow wrote: If not, I think we should avoid adding surface area for something we don't really understand very well. I agree with this. Less is better at this point I think (when appropriate, of course). Of course, the question is where it's appropriate. The reason I prefer to keep readyState is that I've seen things move that way elsewhere. We've recently added it to Document, HTMLMediaElement, EventSource and WebSocket. In any of those examples, can the ready state ever reset from its done position to one of the earlier states? Since we're saying that calling IDBCursor.continue() while there's already a continue pending is not allowed, I'm not as worried about this as I was, but if none of the others are, readyState might at the very least be the wrong name to use. For XMLHttpRequest, Document and HTMLMediaElement the readyState can go back to previous states. Also, do any of those examples have just 2 states? No. I find it a bit odd that IDBRequest.readyState is currently little more than would IDBRequest.result be valid (if the attribute existed). We of course can't just have the attribute be null/undefined to signal such states (since they're cloneable values and thus could be themselves the result). That doesn't allow differenting there was an error and thus no result from still running the request, so no result yet. Throwing would be one option, but isn't a great one. Agree, forcing people to catch exceptions to check for a state/condition isn't good. And what happens if we need to add states in the future? Is there any past experience with this? It seems like it could be tough if not impossible. Are we reasonably sure that LOADING and DONE are all we need? At the very least, maybe we need a third state for the cursor case to say that there's currently a result, but you're not at the end of the cursor yet (and thus DONE would never transition to another state). I don't know what state that would be. And would those states be added while keeping the rest of the API be similar enough that we wouldn't be going down a different code path anyway? / Jonas
Re: [Bug 10430] New: [IndexedDB] We need to make it more clear IDBRequests can be reused and spec readyState's behavior
On Thu, Nov 4, 2010 at 3:47 PM, Jonas Sicking jo...@sicking.cc wrote: On Thu, Nov 4, 2010 at 3:36 PM, Jeremy Orlow jor...@chromium.org wrote: On Thu, Nov 4, 2010 at 12:35 PM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Nov 1, 2010 at 3:17 PM, Shawn Wilsher sdwi...@mozilla.com wrote: On 11/1/2010 5:29 AM, Jeremy Orlow wrote: If not, I think we should avoid adding surface area for something we don't really understand very well. I agree with this. Less is better at this point I think (when appropriate, of course). Of course, the question is where it's appropriate. The reason I prefer to keep readyState is that I've seen things move that way elsewhere. We've recently added it to Document, HTMLMediaElement, EventSource and WebSocket. In any of those examples, can the ready state ever reset from its done position to one of the earlier states? Since we're saying that calling IDBCursor.continue() while there's already a continue pending is not allowed, I'm not as worried about this as I was, but if none of the others are, readyState might at the very least be the wrong name to use. For XMLHttpRequest, Document and HTMLMediaElement the readyState can go back to previous states. Also, do any of those examples have just 2 states? No. I find it a bit odd that IDBRequest.readyState is currently little more than would IDBRequest.result be valid (if the attribute existed). We of course can't just have the attribute be null/undefined to signal such states (since they're cloneable values and thus could be themselves the result). That doesn't allow differenting there was an error and thus no result from still running the request, so no result yet. Throwing would be one option, but isn't a great one. Agree, forcing people to catch exceptions to check for a state/condition isn't good. And what happens if we need to add states in the future? Is there any past experience with this? It seems like it could be tough if not impossible. What about this? It seems as though once people depend on readyState, it can't be changed. Which would be a reason to hold off until we better understand the use cases we'd solve with it. Are we reasonably sure that LOADING and DONE are all we need? At the very least, maybe we need a third state for the cursor case to say that there's currently a result, but you're not at the end of the cursor yet (and thus DONE would never transition to another state). I don't know what state that would be. And would those states be added while keeping the rest of the API be similar enough that we wouldn't be going down a different code path anyway? If we don't have another state, how would you differentiate between IDBRequest.result's null/undefined meaning the value null/undefined and the cursor being at the end? It seems unavoidable. J
Re: [Bug 10430] New: [IndexedDB] We need to make it more clear IDBRequests can be reused and spec readyState's behavior
On Thu, Nov 4, 2010 at 4:03 PM, Jeremy Orlow jor...@chromium.org wrote: On Thu, Nov 4, 2010 at 3:47 PM, Jonas Sicking jo...@sicking.cc wrote: On Thu, Nov 4, 2010 at 3:36 PM, Jeremy Orlow jor...@chromium.org wrote: On Thu, Nov 4, 2010 at 12:35 PM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Nov 1, 2010 at 3:17 PM, Shawn Wilsher sdwi...@mozilla.com wrote: On 11/1/2010 5:29 AM, Jeremy Orlow wrote: If not, I think we should avoid adding surface area for something we don't really understand very well. I agree with this. Less is better at this point I think (when appropriate, of course). Of course, the question is where it's appropriate. The reason I prefer to keep readyState is that I've seen things move that way elsewhere. We've recently added it to Document, HTMLMediaElement, EventSource and WebSocket. In any of those examples, can the ready state ever reset from its done position to one of the earlier states? Since we're saying that calling IDBCursor.continue() while there's already a continue pending is not allowed, I'm not as worried about this as I was, but if none of the others are, readyState might at the very least be the wrong name to use. For XMLHttpRequest, Document and HTMLMediaElement the readyState can go back to previous states. Also, do any of those examples have just 2 states? No. I find it a bit odd that IDBRequest.readyState is currently little more than would IDBRequest.result be valid (if the attribute existed). We of course can't just have the attribute be null/undefined to signal such states (since they're cloneable values and thus could be themselves the result). That doesn't allow differenting there was an error and thus no result from still running the request, so no result yet. Throwing would be one option, but isn't a great one. Agree, forcing people to catch exceptions to check for a state/condition isn't good. And what happens if we need to add states in the future? Is there any past experience with this? It seems like it could be tough if not impossible. What about this? It seems as though once people depend on readyState, it can't be changed. Which would be a reason to hold off until we better understand the use cases we'd solve with it. Again, I struggle to think of what ready-states we would be adding in the future. I agree that future changes to API is something we should always keep in mind, but in this case it seems unlikely to me that 'll need to make changes. And we can never be 100% certain that we won't need to make changes in the future. Are we reasonably sure that LOADING and DONE are all we need? Yes. At the very least, maybe we need a third state for the cursor case to say that there's currently a result, but you're not at the end of the cursor yet (and thus DONE would never transition to another state). I'm not sure I understand this statement. Here is how things work currently when iterating a objectStore with one entry: req = objectStore.openCursor(null, NEXT); // req.readyState == LOADING wait for success event c = event.result; // c == IDBCursor // c.value == value of objectStore entry // req.readyState == DONE c.continue(); // req.readyState == LOADING wait for success event c = event.result; // c == null // req.readyState == DONE So each iteration in the cursor is treated as a separate request, with the exception that it reuses the same request object. If we were to put the result on the request object, you can already tell readyState == DONE because we moved to the next record from readyState == DONE because we ran out of records. I don't know what state that would be. And would those states be added while keeping the rest of the API be similar enough that we wouldn't be going down a different code path anyway? If we don't have another state, how would you differentiate between IDBRequest.result's null/undefined meaning the value null/undefined and the cursor being at the end? It seems unavoidable. The result of cursor navigation is the cursor object itself if a entry was found, and null if the end was reached. This is already in spec. So it's no problem telling them apart. / Jonas
Re: [Bug 10430] New: [IndexedDB] We need to make it more clear IDBRequests can be reused and spec readyState's behavior
On Mon, Nov 1, 2010 at 1:46 AM, Jeremy Orlow jor...@chromium.org wrote: Actually, what's the use case for readyState? I can't think of any uses that we'd want to encourage. Maybe we should just remove it. The use-case that I've heard in similar situations goes something like this: Code makes a request and at some point later hands the request to some other piece of code which is interested in the result. The other piece of code doesn't necessarily know if a result has been returned yet or not. Using readyState it can either simply get .result, or it can add a event listener for the success event and wait for the event to fire. I think that makes sense here too. / Jonas
Re: [Bug 10430] New: [IndexedDB] We need to make it more clear IDBRequests can be reused and spec readyState's behavior
On Mon, Nov 1, 2010 at 9:42 AM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Nov 1, 2010 at 1:46 AM, Jeremy Orlow jor...@chromium.org wrote: Actually, what's the use case for readyState? I can't think of any uses that we'd want to encourage. Maybe we should just remove it. The use-case that I've heard in similar situations goes something like this: Code makes a request and at some point later hands the request to some other piece of code which is interested in the result. The other piece of code doesn't necessarily know if a result has been returned yet or not. Using readyState it can either simply get .result, or it can add a event listener for the success event and wait for the event to fire. I think that makes sense here too. What about the cursor case though? Given that we're re-using the same request object, I really don't think it makes much sense. J
Re: [Bug 10430] New: [IndexedDB] We need to make it more clear IDBRequests can be reused and spec readyState's behavior
On Mon, Nov 1, 2010 at 2:49 AM, Jeremy Orlow jor...@chromium.org wrote: On Mon, Nov 1, 2010 at 9:42 AM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Nov 1, 2010 at 1:46 AM, Jeremy Orlow jor...@chromium.org wrote: Actually, what's the use case for readyState? I can't think of any uses that we'd want to encourage. Maybe we should just remove it. The use-case that I've heard in similar situations goes something like this: Code makes a request and at some point later hands the request to some other piece of code which is interested in the result. The other piece of code doesn't necessarily know if a result has been returned yet or not. Using readyState it can either simply get .result, or it can add a event listener for the success event and wait for the event to fire. I think that makes sense here too. What about the cursor case though? Given that we're re-using the same request object, I really don't think it makes much sense. It makes sense if the code the request is passed to is the one calling continue(), no? / Jonas
Re: [Bug 10430] New: [IndexedDB] We need to make it more clear IDBRequests can be reused and spec readyState's behavior
On Mon, Nov 1, 2010 at 9:57 AM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Nov 1, 2010 at 2:49 AM, Jeremy Orlow jor...@chromium.org wrote: On Mon, Nov 1, 2010 at 9:42 AM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Nov 1, 2010 at 1:46 AM, Jeremy Orlow jor...@chromium.org wrote: Actually, what's the use case for readyState? I can't think of any uses that we'd want to encourage. Maybe we should just remove it. The use-case that I've heard in similar situations goes something like this: Code makes a request and at some point later hands the request to some other piece of code which is interested in the result. The other piece of code doesn't necessarily know if a result has been returned yet or not. Using readyState it can either simply get .result, Actually, this isn't possible. As first proposed by Ben in Changes to IDBRequest and specification of the success and error events, IDBRequest.result was moved just to the success event. So there is no way for something to access the result except through an onsuccess event handler. So the only use case for readyState is figuring out if you need to re-issue a request. or it can add a event listener for the success event and wait for the event to fire. I think that makes sense here too. What about the cursor case though? Given that we're re-using the same request object, I really don't think it makes much sense. It makes sense if the code the request is passed to is the one calling continue(), no? What's the use case for this though? It seems awfully odd that a cursor would be getting passed around after some async call after returning to the event loop. If you haven't returned to the event loop since your last call, then there's no need to check ready state. And things of course become very confusing if you're issued multiple calls. Which brings up the point: what's the behavior if you call .continue() twice? Will your on success fire twice? What if the first result was null (because you're out of results). Should onsuccess fire twice with nulls or only one null and ignore any subsequent continue() requests? Btw, if we do keep readyState around, we should specify that its state changing should be done via the event loop to maintain run to completion semantics. J P.S. I'm happy to discuss all of this f2f tomorrow rather than over email now.
Re: [Bug 10430] New: [IndexedDB] We need to make it more clear IDBRequests can be reused and spec readyState's behavior
On Mon, Nov 1, 2010 at 11:08 AM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Nov 1, 2010 at 3:18 AM, Jeremy Orlow jor...@chromium.org wrote: On Mon, Nov 1, 2010 at 9:57 AM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Nov 1, 2010 at 2:49 AM, Jeremy Orlow jor...@chromium.org wrote: On Mon, Nov 1, 2010 at 9:42 AM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Nov 1, 2010 at 1:46 AM, Jeremy Orlow jor...@chromium.org wrote: Actually, what's the use case for readyState? I can't think of any uses that we'd want to encourage. Maybe we should just remove it. The use-case that I've heard in similar situations goes something like this: Code makes a request and at some point later hands the request to some other piece of code which is interested in the result. The other piece of code doesn't necessarily know if a result has been returned yet or not. Using readyState it can either simply get .result, Actually, this isn't possible. As first proposed by Ben in Changes to IDBRequest and specification of the success and error events, IDBRequest.result was moved just to the success event. So there is no way for something to access the result except through an onsuccess event handler. So the only use case for readyState is figuring out if you need to re-issue a request. Good point, will have to think about that some more. or it can add a event listener for the success event and wait for the event to fire. I think that makes sense here too. What about the cursor case though? Given that we're re-using the same request object, I really don't think it makes much sense. It makes sense if the code the request is passed to is the one calling continue(), no? What's the use case for this though? It seems awfully odd that a cursor would be getting passed around after some async call after returning to the event loop. If you haven't returned to the event loop since your last call, then there's no need to check ready state. And things of course become very confusing if you're issued multiple calls. Consider code that performs some type of merge for example. Placing several requests to different object stores and waiting for response from all of them. So you're assuming that it'd set the same onsuccess handler for multiple cursors and then check the ready state of them all upon each call and only do processing when they're all ready? If so, you can do this other ways (use a counter or wait until you've gotten a call from each event.source you expect), and this solution doesn't seem particularly more elegant to me. If not, I don't understand this use case. Either way, I'm pretty sure this isn't an example of a cursor would be getting passed around after some async call after returning to the event loop which I believe is the only use case where ready state would actually be necessary. Which brings up the point: what's the behavior if you call .continue() twice? Will your on success fire twice? What if the first result was null (because you're out of results). Should onsuccess fire twice with nulls or only one null and ignore any subsequent continue() requests? I think that a call to .continue() on a cursor which still hasn't returned a result from the last call to continue() should result in a NOT_ALLOWED_ERR being thrown. There is just no logical way to honor two calls running at once, so I think the second call should either throw or do nothing. Throw is much better than do nothing. I think that's best for now, and we can spec the behavior in the future if there's demand. I'll file a bug. You didn't respond to Btw, if we do keep readyState around, we should specify that its state changing should be done via the event loop to maintain run to completion semantics. Would you agree? P.S. I'm happy to discuss all of this f2f tomorrow rather than over email now. Speaking of which, would be great to have an agenda. Some of the bigger items are: * Dynamic transactions * Arrays-as-keys * Arrays and indexes (what to do if the keyPath for an index evaluates to an array) * Synchronous API I forked this into another thread. Let's discuss there please. J
Re: [Bug 10430] New: [IndexedDB] We need to make it more clear IDBRequests can be reused and spec readyState's behavior
On Mon, Nov 1, 2010 at 12:00 PM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Nov 1, 2010 at 4:49 AM, Jeremy Orlow jor...@chromium.org wrote: On Mon, Nov 1, 2010 at 11:08 AM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Nov 1, 2010 at 3:18 AM, Jeremy Orlow jor...@chromium.org wrote: On Mon, Nov 1, 2010 at 9:57 AM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Nov 1, 2010 at 2:49 AM, Jeremy Orlow jor...@chromium.org wrote: On Mon, Nov 1, 2010 at 9:42 AM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Nov 1, 2010 at 1:46 AM, Jeremy Orlow jor...@chromium.org wrote: Actually, what's the use case for readyState? I can't think of any uses that we'd want to encourage. Maybe we should just remove it. The use-case that I've heard in similar situations goes something like this: Code makes a request and at some point later hands the request to some other piece of code which is interested in the result. The other piece of code doesn't necessarily know if a result has been returned yet or not. Using readyState it can either simply get .result, Actually, this isn't possible. As first proposed by Ben in Changes to IDBRequest and specification of the success and error events, IDBRequest.result was moved just to the success event. So there is no way for something to access the result except through an onsuccess event handler. So the only use case for readyState is figuring out if you need to re-issue a request. Good point, will have to think about that some more. or it can add a event listener for the success event and wait for the event to fire. I think that makes sense here too. What about the cursor case though? Given that we're re-using the same request object, I really don't think it makes much sense. It makes sense if the code the request is passed to is the one calling continue(), no? What's the use case for this though? It seems awfully odd that a cursor would be getting passed around after some async call after returning to the event loop. If you haven't returned to the event loop since your last call, then there's no need to check ready state. And things of course become very confusing if you're issued multiple calls. Consider code that performs some type of merge for example. Placing several requests to different object stores and waiting for response from all of them. So you're assuming that it'd set the same onsuccess handler for multiple cursors and then check the ready state of them all upon each call and only do processing when they're all ready? If so, you can do this other ways (use a counter or wait until you've gotten a call from each event.source you expect), and this solution doesn't seem particularly more elegant to me. If not, I don't understand this use case. I don't really agree that a counter is more elegant. I said doesn't seem particularly more elegant to me. In other words, I don't think it's enough more elegant that it's worth the additional API surface area. It's also more complicated as you start iterating over the various cursors as you'll then have to wait for a different number of cursors depending on the values that you find. I'm not really following you. I guess in SQL terms you're talking about left/outter joins? Either way, I'm pretty sure this isn't an example of a cursor would be getting passed around after some async call after returning to the event loop which I believe is the only use case where ready state would actually be necessary. Why is it not? Calling .continue() on another cursor is async. I said be necessary. I'm pretty sure code composability _after returning to the event loop_ is the only use case where a readyState would be _necessary_. I'd love to hear a concrete example of why someone might need to do this. As for it being convenient, I don't think think your example is that much more convenient than other possible ways of doing it. Have any developers actually done something like this and found it painful? Is there any code you can point us to that would make the scenario more concrete and clear? If not, I think we should avoid adding surface area for something we don't really understand very well. J
Re: [Bug 10430] New: [IndexedDB] We need to make it more clear IDBRequests can be reused and spec readyState's behavior
On 11/1/2010 5:29 AM, Jeremy Orlow wrote: If not, I think we should avoid adding surface area for something we don't really understand very well. I agree with this. Less is better at this point I think (when appropriate, of course). Cheers, Shawn smime.p7s Description: S/MIME Cryptographic Signature
Re: [Bug 10430] New: [IndexedDB] We need to make it more clear IDBRequests can be reused and spec readyState's behavior
I asked whether LOADING should be 0 rather than 1. (There is no 0 constant
since we removed INITIAL.)
I also asked is it possible to get the IDBRequest object from within the
openCursor/continue events without saving it off somewhere? If not, it
probably should be.
On Thu, Aug 26, 2010 at 2:46 AM, Jonas Sicking jo...@sicking.cc wrote:
On Wed, Aug 25, 2010 at 3:42 PM, Jeremy Orlow jor...@chromium.org wrote:
On Wed, Aug 25, 2010 at 9:29 PM, Jonas Sicking jo...@sicking.cc wrote:
On Wed, Aug 25, 2010 at 8:12 AM, Jeremy Orlow jor...@chromium.org
wrote:
Also, the constants for the ready state should start with 0, not 1.
Also, what happens if someone does the following:
request = objectStore.openCursor();
request.onsuccess(function() {
event.result.continue();
request.abort();
event.result.continue();
}
Also, is it possible to get the IDBRequest object from within the
openCursor/continue events without saving it off somewhere? If not,
it
probably should be.
Didn't we decide to remove IDBRequest.abort()?
Oh yeah...we did. :-)
Will file a bug.
What about the other questions?
Yes, I think we should make it clear that readyState can go from DONE
to LOADING.
All other questions seemed related to abort()?
/ Jonas
Re: [Bug 10430] New: [IndexedDB] We need to make it more clear IDBRequests can be reused and spec readyState's behavior
Also, the constants for the ready state should start with 0, not 1.
Also, what happens if someone does the following:
request = objectStore.openCursor();
request.onsuccess(function() {
event.result.continue();
request.abort();
event.result.continue();
}
Also, is it possible to get the IDBRequest object from within the
openCursor/continue events without saving it off somewhere? If not, it
probably should be.
J
On Wed, Aug 25, 2010 at 3:50 PM, bugzi...@jessica.w3.org wrote:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10430
Summary: [IndexedDB] We need to make it more clear IDBRequests
can be reused and spec readyState's behavior
Product: WebAppsWG
Version: unspecified
Platform: PC
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Indexed Database API
AssignedTo: andr...@google.com
ReportedBy: jor...@chromium.org
QAContact: member-webapi-...@w3.org
CC: m...@w3.org, public-webapps@w3.org
http://www.w3.org/TR/IndexedDB/#idl-def-IDBRequest right now clearly
assumes
IDBRequests are only going to be used once. But IDBCursor.continue()
reuses
them. At the very least, we'll need to clean up the .readyState section to
make it clear it's possible to go from DONE to LOADING (or we can remove it
altogether?). I think some notes explicitly pointing out that some parts
of
the API reuse them would be helpful as well.
--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
Re: [Bug 10430] New: [IndexedDB] We need to make it more clear IDBRequests can be reused and spec readyState's behavior
On Wed, Aug 25, 2010 at 4:12 PM, Jeremy Orlow jor...@chromium.org wrote:
Also, the constants for the ready state should start with 0, not 1.
Also, what happens if someone does the following:
request = objectStore.openCursor();
request.onsuccess(function() {
event.result.continue();
request.abort();
event.result.continue();
}
After thinking about this more, I think we have 2 options: either .abort()
kills all pending and future requests on that IDBRequest object or it
cancels all requests that have been made up until that point. I.e. if we
did
event.result.continue();
event.result.continue();
event.abort();
event.result.continue();
event.result.continue();
Either the 3rd and 4th results should be returned or no results should be
returned, depending on what we decide here.
Unless someone can present a good use case for why abort shouldn't abort
pending and future requests, I suggest we go with that behavior.
Also, is it possible to get the IDBRequest object from within the
openCursor/continue events without saving it off somewhere? If not, it
probably should be.
J
On Wed, Aug 25, 2010 at 3:50 PM, bugzi...@jessica.w3.org wrote:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10430
Summary: [IndexedDB] We need to make it more clear IDBRequests
can be reused and spec readyState's behavior
Product: WebAppsWG
Version: unspecified
Platform: PC
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Indexed Database API
AssignedTo: andr...@google.com
ReportedBy: jor...@chromium.org
QAContact: member-webapi-...@w3.org
CC: m...@w3.org, public-webapps@w3.org
http://www.w3.org/TR/IndexedDB/#idl-def-IDBRequest right now clearly
assumes
IDBRequests are only going to be used once. But IDBCursor.continue()
reuses
them. At the very least, we'll need to clean up the .readyState section
to
make it clear it's possible to go from DONE to LOADING (or we can remove
it
altogether?). I think some notes explicitly pointing out that some parts
of
the API reuse them would be helpful as well.
--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
Re: [Bug 10430] New: [IndexedDB] We need to make it more clear IDBRequests can be reused and spec readyState's behavior
On Wed, Aug 25, 2010 at 4:41 PM, Jeremy Orlow jor...@chromium.org wrote:
On Wed, Aug 25, 2010 at 4:12 PM, Jeremy Orlow jor...@chromium.org wrote:
Also, the constants for the ready state should start with 0, not 1.
Also, what happens if someone does the following:
request = objectStore.openCursor();
request.onsuccess(function() {
event.result.continue();
request.abort();
event.result.continue();
}
After thinking about this more, I think we have 2 options: either .abort()
kills all pending and future requests on that IDBRequest object or it
cancels all requests that have been made up until that point. I.e. if we
did
event.result.continue();
event.result.continue();
event.abort();
event.result.continue();
event.result.continue();
Either the 3rd and 4th results should be returned or no results should be
returned, depending on what we decide here.
Unless someone can present a good use case for why abort shouldn't abort
pending and future requests, I suggest we go with that behavior.
Sorry for the spam, but is there any reason that ABORTED is not one of the
readyStates?
Also, is it possible to get the IDBRequest object from within the
openCursor/continue events without saving it off somewhere? If not, it
probably should be.
J
On Wed, Aug 25, 2010 at 3:50 PM, bugzi...@jessica.w3.org wrote:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10430
Summary: [IndexedDB] We need to make it more clear IDBRequests
can be reused and spec readyState's behavior
Product: WebAppsWG
Version: unspecified
Platform: PC
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Indexed Database API
AssignedTo: andr...@google.com
ReportedBy: jor...@chromium.org
QAContact: member-webapi-...@w3.org
CC: m...@w3.org, public-webapps@w3.org
http://www.w3.org/TR/IndexedDB/#idl-def-IDBRequest right now clearly
assumes
IDBRequests are only going to be used once. But IDBCursor.continue()
reuses
them. At the very least, we'll need to clean up the .readyState section
to
make it clear it's possible to go from DONE to LOADING (or we can remove
it
altogether?). I think some notes explicitly pointing out that some parts
of
the API reuse them would be helpful as well.
--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
Re: [Bug 10430] New: [IndexedDB] We need to make it more clear IDBRequests can be reused and spec readyState's behavior
On Wed, Aug 25, 2010 at 8:12 AM, Jeremy Orlow jor...@chromium.org wrote:
Also, the constants for the ready state should start with 0, not 1.
Also, what happens if someone does the following:
request = objectStore.openCursor();
request.onsuccess(function() {
event.result.continue();
request.abort();
event.result.continue();
}
Also, is it possible to get the IDBRequest object from within the
openCursor/continue events without saving it off somewhere? If not, it
probably should be.
Didn't we decide to remove IDBRequest.abort()?
/ Jonas
Re: [Bug 10430] New: [IndexedDB] We need to make it more clear IDBRequests can be reused and spec readyState's behavior
On Wed, Aug 25, 2010 at 9:29 PM, Jonas Sicking jo...@sicking.cc wrote:
On Wed, Aug 25, 2010 at 8:12 AM, Jeremy Orlow jor...@chromium.org wrote:
Also, the constants for the ready state should start with 0, not 1.
Also, what happens if someone does the following:
request = objectStore.openCursor();
request.onsuccess(function() {
event.result.continue();
request.abort();
event.result.continue();
}
Also, is it possible to get the IDBRequest object from within the
openCursor/continue events without saving it off somewhere? If not, it
probably should be.
Didn't we decide to remove IDBRequest.abort()?
Oh yeah...we did. :-)
Will file a bug.
What about the other questions?
Re: [Bug 10430] New: [IndexedDB] We need to make it more clear IDBRequests can be reused and spec readyState's behavior
On Wed, Aug 25, 2010 at 3:42 PM, Jeremy Orlow jor...@chromium.org wrote:
On Wed, Aug 25, 2010 at 9:29 PM, Jonas Sicking jo...@sicking.cc wrote:
On Wed, Aug 25, 2010 at 8:12 AM, Jeremy Orlow jor...@chromium.org wrote:
Also, the constants for the ready state should start with 0, not 1.
Also, what happens if someone does the following:
request = objectStore.openCursor();
request.onsuccess(function() {
event.result.continue();
request.abort();
event.result.continue();
}
Also, is it possible to get the IDBRequest object from within the
openCursor/continue events without saving it off somewhere? If not, it
probably should be.
Didn't we decide to remove IDBRequest.abort()?
Oh yeah...we did. :-)
Will file a bug.
What about the other questions?
Yes, I think we should make it clear that readyState can go from DONE
to LOADING.
All other questions seemed related to abort()?
/ Jonas
