- From: Nolan Lawson <notifications@github.com>
- Date: Sun, 09 Nov 2025 14:45:13 -0800
- To: w3c/IndexedDB <IndexedDB@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/IndexedDB/pull/479/c3508906309@github.com>
nolanlawson left a comment (w3c/IndexedDB#479)
Sorry for the delay. I've made the following changes:
- Renamed the existing algorithm to "_recursively_ convert a value to a key" and made the new "convert a value to a key" take an optional `transaction`. ("Recursively..." is not an amazing name, and I'm open to suggestions. :slightly_smiling_face:)
- Note: I found this tricky to refactor given the necessary try/catch logic and recursion in the existing algorithm; I hope it's okay to have two separate algorithms.
- Refactored "is a potentially valid key range" and "convert a value to a key range" to pass in the `transaction`.
- The `IDBKeyRange` methods (e.g. `only`/`lowerBound`) do not pass `transaction` since they aren't explicitly associated with a transaction. Same for `indexedDB.cmp()`.
- Similarly, "extract a key from a value using a key path" does not pass `transaction` since there is no explicit transaction, and plus its inputs are already "sanitized" in the sense that they are derived from the store's key path rather than arbitrary user input.
The WPT tests will be a bit tricky to cover all these new scenarios, so I wanted to check if the spec changes look good first. (For example, "Creating a request to retrieve multiple items" calls the new transaction-checking logic multiple times, so you could imagine writing a test where the getter uses a counter to only trigger the `TransactionInactiveError` on the 1st, 2nd, or 3rd time.)
--
Reply to this email directly or view it on GitHub:
https://github.com/w3c/IndexedDB/pull/479#issuecomment-3508906309
You are receiving this because you are subscribed to this thread.
Message ID: <w3c/IndexedDB/pull/479/c3508906309@github.com>
Received on Sunday, 9 November 2025 22:45:17 UTC