Re: [w3c/IndexedDB] asynchronously execute a request source object confusion (Issue #445)

inexorabletash left a comment (w3c/IndexedDB#445)

I suspect the text around sources probably predates splitting the concepts of the abstract "internal" object store/index sitting in the database from the handles (which map 1:1 with the JS-exposed interfaces). So yes, we would want to fix this.

From looking at how the _source_ is used (namely, _"Let transaction be the transaction associated with source."_) a request's  _source_ should be a handle object rather than the internal object, since handle objects have associated transactions. Also, ultimately calling `request.source` is going to give back an `IDBObjectStore`, `IDBIndex`, or `IDBCursor` so in the former two cases it needs to be the handle object. To do so, we probably need to do a more intrusive change where either (a) the cursor's _source_ is a handle object (and do the extra hop to get from the handle to the internal object), _or_ (b) the cursor holds onto both a handle source  _and_ an internal source. 

For cursors we need to look carefully at the tests and the behaviors of shipping implementations because there are two cases:

* For operations that create or advance the cursor (openCursor, continue, continuePrimaryKey, advance) I believe the `source` is intended to be the `IDBObjectStore` / `IDBIndex`
* For operations that add work in the transaction (delete, update) I believe the `source` is intended to be the `IDBCursor`.

... but I don't remember very well. Anyway, some archaeology is needed here. PR's welcome!

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/IndexedDB/issues/445#issuecomment-2776797059
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/IndexedDB/issues/445/2776797059@github.com>