This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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?
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.
I didn't make .close() return a IDBRequest since no use case was mentioned.