API to enumerate databases

[inexorabletash]

Moved from: https://www.w3.org/Bugs/Public/show_bug.cgi?id=16137

Discussions:

http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1528.html
http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1537.html

Critical bit: how do we do this such that the answer isn't obsolete as soon as it's given, since there are no transactions over the set-of-databases.

[inexorabletash]

FWIW, based on early feedback when IDB was shiny and new, Chrome implemented/shipped a prefixed API for this:

partial interface IDBFactory {
  IDBRequest webkitGetDatabaseNames();
};

Result is a DOMStringList (see #28) of the names, purely a snapshot at the time the request is processed.

[aliams]

I think we should keep this around given that it's useful for IDB libraries and diagnostic purposes. I recommend that we pursue a standardized non-prefixed version of this API e.g. getDatabaseNames().

I reckon no attempt needs to be made to ensure the results remain valid after the function call returns values. I would suggest leaving it up to the application author to deal with it.

That said, a separate function like hasDatabase(name) would be useful, with the proviso that other open/create requests for the same name would be queued until after the current code finishes dealing with IndexedDB (I'm not familiar with the implementation enough to suggest a specific mechanism for this).

[pwnall]

@Gilead The only mechanism I can think of would be to hold onto a lock for the database, which is what you get with indexedDB.open.

[aliams]

It could be treated just like another transaction (such as versionchange, readwrite, readonly) in the sense that no other transactions can execute while getDatabaseNames is running.

[pwnall]

@aliams Sorry if I misunderstood your suggestion, but merely serializing the execution of getDatabaseNames doesn't seem sufficient to me. Another transaction could sneak in between the getDatabaseNames transaction and a subsequent indexedDB.open transaction. This results in an unintuitive behavior where indexedDB.open would error out when given a database returned by getDatabaseNames, because a delete transaction snuck between getDatabaseNames and indexedDB.open.

[aliams]

That's a fair point @pwnall. Are you thinking that after getDatabaseNames is called, a subsequent indexedDB.open on a database would release the previously set lock? Is that to say that you could only call getDatabaseNames before any .open is called?

[pwnall]

@aliams Thank you for the clarifying question! I was (unclearly) trying to point out that an implementation of @Gilead's hasDatabase() suggestion would require the same locking as indexedDB.open, so applications might as well use indexedDB.open instead.

I think it makes sense to specify getDatabaseNames without any consistency guarantees. Specifically, I'd only guarantee that at a quiescent time (there is no IndexedDB connection to any database in the current origin), the result would be consistent with all the successful open / delete requests. Otherwise, the database list might contain databases that were already deleted and might miss databases that were created, since the last quiescent time. The latter condition aims formalize the idea that an implementation will do its best to make the result useful, but we could go for something weaker/stronger if it's easier to test.

[aliams]

That makes sense to me! I agree that getDatabaseNames shouldn't need to have strong guarantees.

[jancona]

This issue is for a Chrome extension that is an administrative interface for PouchDB (which is implemented on top of IndexedDB). The removal of webkitGetDatabaseNames() has broken it, because it needs to be able to find a database to administer.

Note that this use case doesn't require any consistency guarantees. FWIW, most relational databases I've worked with don't provide transactional guarantees for these sorts of functions.