Intent to Implement: IndexedDB database enumeration API
Andreas Butler
Contact emails
andrea...@chromium.org, dmu...@chromium.org
Explainer
https://andreas-butler.github.io/idb-databases/EXPLAINER
Design doc/Spec
https://pr-preview.s3.amazonaws.com/w3c/IndexedDB/pull/240.html#dom-idbfactory-databases
Summary
Adding databases enumeration function to Chromium implementation of IndexedDB to allow access to a list of current IndexedDB databases accessible by the frame’s origin.
Motivation
At present there is no standard method for retrieving a list of all existing indexedDB databases for a given frame. Providing such a list seems not only reasonable but obviously useful. Without such a list, for example, developers cannot easily iterate over all existing databases for even such basic reasons as deleting all existing IndexedDB database. (see: https://github.com/w3c/IndexedDB/issues/31#issuecomment-324756055, https://github.com/w3c/IndexedDB/issues/31#issuecomment-339070628,
https://stackoverflow.com/questions/15234363/indexeddb-view-all-databases-and-object-stores ).
There was past objection to implementing a standardized enumeration function due to its inherently racy nature (what is returned is an asynchronous snapshot of database information that may or may not be obsolete by the time it is received due to the processing of other create/delete/upgrade requests to IndexedDB). With the gradual passage of time, objections have given way to a consensus that such a feature is in fact worthwhile (https://github.com/w3c/IndexedDB/issues/31).
There was a previous nonstandard implementation of databases() in chromium named webkitGetDatabaseNames() that was deprecated due to its nonstandard nature. Its existence nonetheless made common patterns such as deleting all indexedDB instances quite simple (see: https://gist.github.com/rmehner/b9a41d9f659c9b1c3340 ).
To further emphasize the case for database enumeration with regards to database deletion, the current deletion alternatives are to use the Clear-Site-Data header, which will not only clear all IndexedDB databases, but all state associated with the current origin, or to keep meticulous records of any code that has been deployed to a given origin (even experimental code). In this case, the former solution is overkill, while the latter has been discounted by large orgs who have admitted the near impossibility of maintaining such records, and so an explicit database enumeration function will have clear benefits.
Risks:
Interoperability and Compatibility
Edge: positive signals
LGTM’d by edge PM: https://github.com/w3c/IndexedDB/pull/240
Firefox: positive signals
https://github.com/w3c/IndexedDB/issues/31#issuecomment-323635338
Safari: Positive signals
https://github.com/w3c/IndexedDB/issues/31#issuecomment-324791267
Web developers: Positive signals
https://github.com/w3c/IndexedDB/issues/31#issuecomment-324756055 ,
https://github.com/w3c/IndexedDB/issues/31#issuecomment-323882274 ,
https://github.com/w3c/IndexedDB/issues/31#issuecomment-339070628 ,
https://stackoverflow.com/questions/15234363/indexeddb-view-all-databases-and-object-stores
Ergonomics
The database enumeration function will return a Promise of a Sequence of IDBDatabaseInfo objects. The IDBDatabaseInfo objects will essentially be dictionaries of informational fields relevant to the IndexedDB databases accessible by the frame.
Returning the database information as a list wrapped in a Promise was chosen over returning an IDBRequest object, contrary to what has previously been the pattern with IndexedDB functions because web development is moving in the direction of Promise-based asynchronous behaviour. As developers will not have been previously exposed to this standardized database enumeration function it is not expected that breaking the established pattern will cause serious issues. Additionally, keeping the IDBRequest object restricted to interactions with uniquely specified databases (eg: requests for opening / closing particular database instances ) was determined to be a cleaner design choice.
Activation
As this feature is fairly intuitive and simple (single function addition to existing API), it is not expected that it will be difficult for developers to take advantage of it immediately.
Debuggability
It is easy to see the list of existing IndexedDB databases using the current DevTools implementation, and thus debugging will be relatively simple for developers.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes
Is this feature fully tested by web-platform-tests?
Writing tests currently
Link to entry on the feature dashboard
https://www.chromestatus.com/feature/6084476278931456
Requesting approval to ship?
No
j.j.
There was a previous nonstandard implementation of databases() in chromium named webkitGetDatabaseNames() that was deprecated due to its nonstandard nature.
Joe Medley
--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f737e3ac-01d4-4e6f-b177-4462202903df%40chromium.org.
Joshua Bell
There was a previous nonstandard implementation of databases() in chromium named webkitGetDatabaseNames() that was deprecated due to its nonstandard nature.
What's the satus? This is conflicting:
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f737e3ac-01d4-4e6f-b177-4462202903df%40chromium.org.
Andreas Butler
Andreas,Do you have a tracking bug for this?If an API's not documented it doesn't exist.
On Wed, Sep 19, 2018 at 3:00 AM j.j. <fri...@jeka.info> wrote:
--There was a previous nonstandard implementation of databases() in chromium named webkitGetDatabaseNames() that was deprecated due to its nonstandard nature.
What's the satus? This is conflicting:
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+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f737e3ac-01d4-4e6f-b177-4462202903df%40chromium.org.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJUhtG_NXt3%3DavYwx-PH7AhwOc12-msPrfK1CtH1uTjPSa2zqg%40mail.gmail.com.