Bug 1168606 Comment 51 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

(In reply to Simon Giesecke [:sg] [he/him] from comment #50)
> When implementing this, I found a problem with a web-platform-test here: https://searchfox.org/mozilla-central/source/testing/web-platform/tests/IndexedDB/idbcursor_iterating.htm#54
> 
> This deletes the next record after the current cursor position via IDBObjectStore.delete, and expects that the cursor does not iterate to that deleted record. If that record has been preloaded, the cursor however does not take notice of that with the current implementation approach, and I don't see a way right now how to resolve this efficiently. If we need to check in the child for each record if it still exists, then preloading will become ineffective IMO. However, I am not sure if this web-platform-test is correct. Does the specification really imply that the cursor must take notice of this?
> 
> Note that this issue doesn't exist if IDBCursor.delete is called. In that case, we can invalidate the cached records, since this is local to the cursor object. (Apart from that probably not being necessary at all, since IDBCursor.delete can only delete the current record, but not a subsequent one.)

I think I resolved this after discussion with :ytausky, at least for the particular case mentioned above: the delete call is done in the same transaction the cursor was opened from, and in that case, we can actually notify the cursor.

As Yaron pointed out, the spec says "It is possible for the list of records which the cursor is iterating over to change before the full range of the cursor has been iterated." and some more related things in the rest of the paragraph, but this can interpreted in different ways. One interpretation (and Yaron thought this is more likely) is that this states that the cursor indeed should observe such changes, at least in some cases (and the test referenced above materializes this). However, another interpretation would just be that it is a note to the implementor not to try to maintain the position as an index (which is indeed explicitly stated in the next sentence: "It is possible for the list of records which the cursor is iterating over to change before the full range of the cursor has been iterated."), which would be invalidated by deletion operation, and saying nothing about the observability of changes.

What this still leaves open are changes from other transactions, which someone might think to have synchronized in some way. The spec mentions nothing about that either. In general for database, I think that transaction isolation levels won't require any changes from other transactions to be observable, but only limit changes that might or might not be observable. But a clarification to the spec in this regard wouldn't hurt.
(In reply to Simon Giesecke [:sg] [he/him] from comment #50)
> When implementing this, I found a problem with a web-platform-test here: https://searchfox.org/mozilla-central/source/testing/web-platform/tests/IndexedDB/idbcursor_iterating.htm#54
> 
> This deletes the next record after the current cursor position via IDBObjectStore.delete, and expects that the cursor does not iterate to that deleted record. If that record has been preloaded, the cursor however does not take notice of that with the current implementation approach, and I don't see a way right now how to resolve this efficiently. If we need to check in the child for each record if it still exists, then preloading will become ineffective IMO. However, I am not sure if this web-platform-test is correct. Does the specification really imply that the cursor must take notice of this?
> 
> Note that this issue doesn't exist if IDBCursor.delete is called. In that case, we can invalidate the cached records, since this is local to the cursor object. (Apart from that probably not being necessary at all, since IDBCursor.delete can only delete the current record, but not a subsequent one.)

I think I resolved this after discussion with :ytausky, at least for the particular case mentioned above: the delete call is done in the same transaction the cursor was opened from, and in that case, we can actually notify the cursor.

As Yaron pointed out, the spec says "It is possible for the list of records which the cursor is iterating over to change before the full range of the cursor has been iterated." and some more related things in the rest of the paragraph, but this can interpreted in different ways. One interpretation (and Yaron thought this is more likely) is that this states that the cursor indeed should observe such changes, at least in some cases (and the test referenced above materializes this). However, another interpretation would just be that it is a note to the implementor not to try to maintain the position as an index (which is indeed explicitly stated in the next sentence: "It is possible for the list of records which the cursor is iterating over to change before the full range of the cursor has been iterated."), which would be invalidated by deletion operation, and saying nothing about the observability of changes.

What this still leaves open are changes from other transactions, which someone might think to have synchronized in some way. The spec mentions nothing about that either. In general for database, I think that transaction isolation levels won't require any changes from other transactions to be observable, but only limit changes that might or might not be observable. But a clarification to the spec in this regard wouldn't hurt.

NB: I found the discussion leading to this wording, see https://www.w3.org/Bugs/Public/show_bug.cgi?id=10088 and the thread starting with http://lists.w3.org/Archives/Public/public-webapps/2010JulSep/0056.html
(In reply to Simon Giesecke [:sg] [he/him] from comment #50)
> When implementing this, I found a problem with a web-platform-test here: https://searchfox.org/mozilla-central/source/testing/web-platform/tests/IndexedDB/idbcursor_iterating.htm#54
> 
> This deletes the next record after the current cursor position via IDBObjectStore.delete, and expects that the cursor does not iterate to that deleted record. If that record has been preloaded, the cursor however does not take notice of that with the current implementation approach, and I don't see a way right now how to resolve this efficiently. If we need to check in the child for each record if it still exists, then preloading will become ineffective IMO. However, I am not sure if this web-platform-test is correct. Does the specification really imply that the cursor must take notice of this?
> 
> Note that this issue doesn't exist if IDBCursor.delete is called. In that case, we can invalidate the cached records, since this is local to the cursor object. (Apart from that probably not being necessary at all, since IDBCursor.delete can only delete the current record, but not a subsequent one.)

I think I resolved this after discussion with :ytausky, at least for the particular case mentioned above: the delete call is done in the same transaction the cursor was opened from, and in that case, we can actually notify the cursor.

As Yaron pointed out, the spec says "It is possible for the list of records which the cursor is iterating over to change before the full range of the cursor has been iterated." and some more related things in the rest of the paragraph, but this can interpreted in different ways. One interpretation (and Yaron thought this is more likely) is that this states that the cursor indeed should observe such changes, at least in some cases (and the test referenced above materializes this). However, another interpretation would just be that it is a note to the implementor not to try to maintain the position as an index (which is indeed explicitly stated in the next sentence: "It is possible for the list of records which the cursor is iterating over to change before the full range of the cursor has been iterated."), which would be invalidated by deletion operation, and saying nothing about the observability of changes.

NB: I found the discussion leading to this wording, see https://www.w3.org/Bugs/Public/show_bug.cgi?id=10088 and the thread starting with http://lists.w3.org/Archives/Public/public-webapps/2010JulSep/0056.html

Following up on this, I found the statements in https://w3c.github.io/IndexedDB/#transaction-scheduling, which clarify the isolation of multiple transactions (while never using the term "isolation"). I am not sure which way suggested in the box after read-only transactions we take, however I haven't seen any mention of snapshots taken in the code, so I assume we don't do that.

Back to Bug 1168606 Comment 51