Intent to Prototype: IndexedDB getAllRecords()

[Chromestatus]

Contact emails

ste...@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.