Re: [w3c/IndexedDB] API to enumerate databases (#31)

>  On your question about why implementations would need to block, I can imagine an implementation where all the IDB metadata for an origin lives in a single table. versionchange would require a write lock on the table, and getAllDatabases would require a read lock on the table.

Then such implementations could not resolve the getAllDatabases() request until the version change transaction(s) are finished, but the other implementations could. That's fine.

> Can we agree to spec the method in such a way that an implementation that needs to block on versionchange (i.e. not respond until the versionchange completes) can do so, and an implementation that doesn't need to block is free to return inconsistent data?

This is what I'm voting for.

As an aside, "inconsistent data" is being thrown around a lot here. I'm thinking the term is wrong for this. It's "racy data" in all implementations, in that whatever is returned by the getAllDatabases call might be partially (or fully) out of date by the time it is received, and even more out of date by the time it is used.

And, again, we're fine with that. 

Any attempt to guarantee that the results of getAllDatabases() somehow lock all of the relevant databases from use by all other web contexts, therefore getting rid of the raciness... Is something that would be overtly complex, over engineered, and of dubious value.
(IMHO)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/IndexedDB/issues/31#issuecomment-323757468