This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 11097 - [IndexedDB] Behavior of .close() is not completely specified
Summary: [IndexedDB] Behavior of .close() is not completely specified
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: Indexed Database API (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: This bug has no owner yet - up for the taking
QA Contact: public-webapps-bugzilla
Depends on:
Reported: 2010-10-19 17:36 UTC by Jeremy Orlow
Modified: 2011-03-08 19:14 UTC (History)
4 users (show)

See Also:


Description Jeremy Orlow 2010-10-19 17:36:23 UTC
The spec defines what should happen if .transaction() is called after .close(), but it doesn't specify the rest. For example, what happens if I call database.objectStores or .version. Or I touch my IDBIndex object. Or so on. It seems like most if not all of this should return exceptions.

It's also kind of odd that we have different behavior specified for when .close() is called and when we actually finish the close. Maybe we should return an IDBRequest object and fire an onsuccess when the close is complete?
Comment 1 Jonas Sicking (Not reading bugmail) 2010-10-20 00:55:41 UTC
I'd be fine with .close() returning a IDBRequest with a success handler. Though what is the use case? One complication is what happens if .close() is called multiple times.

It seems more important to be able to tell what the current state of the IDBDatabase is, so maybe we should add a readyState property which can be:

OPEN     // initial state
CLOSING  // after .close() is called if there are running transactions.
CLOSED   // after all transactions are done running.

Touching IDBIndexes and IDBObjectStores is implicitly already defined, they basically work just like normal. I.e. if you're inside a success-callback for the transaction they are connected to you can still place requests against them. Otherwise you can't.

That leaves .name, .version and .objectStores. IMHO We should keep properties working at least as long as existing transactions are running since .close() allows all existing transactions to finish before the IDBDatabase is truly closed.

Once the IDBDatabase is truly closed, I don't have a strong preference, but I don't see much harm in letting them keep "working". I.e. let them remain unchanged for the remaining lifetime of the object.
Comment 2 Jonas Sicking (Not reading bugmail) 2011-03-08 19:14:23 UTC
I didn't make .close() return a IDBRequest since no use case was mentioned.