Contact emails
stev...@microsoft.com, rah...@microsoft.com

Explainer
https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/IndexedDbGetAllEntries/explainer.md


Specification
None


Summary

getAllRecords() combines getAllKeys() with getAll() to enumerate both primary 
keys and values at the same time. For an IDBIndex, getAllRecords() also 
provides the record's index key in addition to the primary key and value. 
Lastly, getAllRecords() offers a new direction option to enumerate records 
sorted by key in descending order. This proposal adds getAllRecords() to both 
IDBObjectStore and IDBIndex. getAllRecords() creates a new IDBRequest that 
queries its IDBObjectStore or IDBIndex owner. The IDBRequest completes with an 
array of IDBRecord results. Each IDBRecord contains the key, primaryKey and 
value attributes. For IDBIndex, key is the record's index key. For 
IDBObjectStore, both key and primaryKey return the same value. The pre-existing 
IDBCursorWithValue interface contains the same attributes and values for both 
IDBObjectStore and IDBIndex. However, unlike getAllRecords(), a cursor may only 
read one record at a time.



Blink component
Blink>Storage>IndexedDB


Motivation

getAllRecords() can decrease the latency of database read operations. By 
retrieving the primary key, value and index key for database records through a 
single operation, getAllRecords() reduces the number of JavaScript events 
required to read records. Each JavaScript event runs as a task on the main 
JavaScript thread. These tasks can introduce overhead when reading records 
requires a sequence of tasks that go back and forth between the main JavaScript 
thread and the IndexedDB I/O thread. For batched record iteration, for example, 
retrieving N records at a time, the primary and index keys provided by 
getAllRecords() can eliminate the need for an IDBCursor, which further reduces 
the number of JavaScript events required. To read the next N records, instead 
of advancing a cursor to determine the range of the next batch, getAllRecords() 
can use the primary key or the index key retrieved by the results from the 
previous batch.



Initial public proposal
https://github.com/w3c/IndexedDB/issues/206#issuecomment-566205600


Search tags
IndexedDB, getAllRecords, IDBObjectStore, IDBIndex


TAG review
None


TAG review status
Pending


Risks




Interoperability and Compatibility

None


Gecko: No signal

WebKit: No signal

Web developers: Positive 
(https://nolanlawson.com/2021/08/22/speeding-up-indexeddb-reads-and-writes) 
Developers have reported the limitations addressed by getAllRecords(), 
including: "You cannot build a paginated cursor in descending order." The 
following includes another example where getAll() could help but needs to 
retrieve the index key and primary key: 
https://stackoverflow.com/questions/44349168/speeding-up-indexeddb-search-with-multiple-workers

Other signals:


WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it 
has potentially high risk for Android WebView-based applications?

None




Debuggability

None



Is this feature fully tested by web-platform-tests?
Yes
The prototype adds tentative WPT tests for IDBObjectStore::GetAllRecords() and 
IDBIndex::getAllRecords().



Flag name on chrome://flags



Finch feature name
IndexedDbGetAllRecords


Requires code in //chrome?
False


Tracking bug
https://issues.chromium.org/issues/40746016


Estimated milestones

No milestones specified



Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5124331450138624?gate=5190164708851712


This intent message was generated by Chrome Platform Status.

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/67214ee9.2b0a0220.32f303.0857.GAE%40google.com.

Reply via email to