This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
A few people from mozilla recently made a proposal for improvements to the Indexed DB asynchronous interface. The proposal in its entirety is here: http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0717.html http://docs.google.com/View?id=dfs2skx2_4g3s5f857 The main changes are: 1. Once a database has been opened (a database connection has been established) read access to meta-data, such as objectStore and index names, is synchronous. Changes to such meta data, such as creating objectStores and indexes, is still asynchronous. 2. You can only add "requests" to read and write data to a transaction during a transaction callback. There is one exception to this rule (more below). 3. Transactions are automatically committed. Once a request in a transaction finishes and there are no more requests queued against the transaction, the transaction is committed. 4. Cursors do not fire error events if a request to open a cursor yields zero results or when iterating using a cursor reaches the end of the found results. Instead, a success event is fired which indicates that no more results are available. 5. All reads and writes are done through transactions. However in some places the transaction is implicit (but defined). 6. Access to index objects are done through API on objectStore objects. 7. Separate functions for add/add-or-modify. 8. Calling abort() on read request always cancels the request, even if the implementation has already read the data and is ready to fire a success event. The error event is always fired if abort() is called, and the success event is suppressed. 9. You are allowed to have multiple transactions per database connection. However if they use overlapping tables, only the first one will receive events until it is finished (with the usual exceptions of allowing multiple readers of the same table). There was one thing in our initial proposal which have met resistance and so have been dropped: We're not suggesting any changes to factory functions for KeyRanges at this point. KeyRange construction changes might not be needed and in any case is orthogonal to the rest of the proposal so lets not discuss it now. Additionally, some people were concerned about the getAll/getObjectAll functions. Though toward the end of that discussion it seemed like people were less concerned so we might want to include it after all. In any case mozilla is planning on putting it in our preliminary implementation. / Jonas
Updating the spec for this proposal and I have several questions: 1. Why does creating a transaction return synchronously? If implementations are to acquire locks prior to offering a transaction handle, this could take time. The answer to this question also affects the implicit transaction created in the objectStore call. 2. Is there any meaning to the IDBRequest readyState of INITIAL? 3. How can you transactionally create or remove object stores and indices? I propose that we add a mandatory transaction parameter to related methods. 4. Is there a reason that the list of object stores available to a transaction (based on acquired locks) is not exposed as an attribute in the transaction interface? 5. An explicit commit is available for use, but is not required to be used. Transactions are committed automatically at end of scope or can be manually committed at the right time. This is beneficial to applications that want advanced control, without burdening less sophisticated programs. 6. What is the meaning of mode in a transaction? This is a new concept for the spec. In practice, some object stores/indices will be used in a read only and some others in a read-write mode. 7. Why do "schema" modification operations not produce an IDBTransactionEvent and instead produce IDBSuccessEvent? As already discussed on the list a long time ago, it is necessary to perform such operations in an explicit transaction.
(In reply to comment #1) > Updating the spec for this proposal and I have several questions: > > 1. Why does creating a transaction return synchronously? If implementations are > to acquire locks prior to offering a transaction handle, this could take time. > The answer to this question also affects the implicit transaction created in > the objectStore call. The lock will be acquired asynchronously. Until the lock is acquired no callbacks will be done for any requests placed to the transaction. > 2. Is there any meaning to the IDBRequest readyState of INITIAL? No, it should be removed. > 4. Is there a reason that the list of object stores available to a transaction > (based on acquired locks) is not exposed as an attribute in the transaction > interface? No. Is there a use case though? > 5. An explicit commit is available for use, but is not required to be used. > Transactions are committed automatically at end of scope or can be manually > committed at the right time. This is beneficial to applications that want > advanced control, without burdening less sophisticated programs. Can you give an example of a "applications that want advanced control"? I don't think it would be that hard to implement, though it means that we have to define a lot of edge cases in the spec. For example what happens to requests that have started but not yet finished? And requests that have finished but not yet had their 'success' event fired. And what happens with requests that are placed after commit() is called but before the commit has been executed. I'm also worried that it makes it easy for an application to shoot itself in the foot. > 6. What is the meaning of mode in a transaction? This is a new concept for the > spec. In practice, some object stores/indices will be used in a read only and > some others in a read-write mode. The way things work in the new API is that opening a database doesn't hold any locks other than ones related to version changes. This is so that this connection can be left open for very long periods of time. Instead you grab read or write locks when starting a transaction. Thus the mode on the transaction indicates if the transaction was opened for read access or read/write access. > 3. How can you transactionally create or remove object stores and indices? I > propose that we add a mandatory transaction parameter to related methods. > 7. Why do "schema" modification operations not produce an IDBTransactionEvent > and instead produce IDBSuccessEvent? As already discussed on the list a long > time ago, it is necessary to perform such operations in an explicit > transaction. Hmm.. this is an interesting question. Might be good to raise this on the list. One solution would be to require version changes if you want transactionality. We could even require that schema modifications happen inside a version change transaction. Another solution is to add a 3rd mode, on top of READ and READ_WRITE which allows for schema modifications and only allow schema modifications inside such a transaction. setVersion would of course create such a transaction as well. I think I like the latter idea the best.
(In reply to comment #2) > > 3. How can you transactionally create or remove object stores and indices? I > > propose that we add a mandatory transaction parameter to related methods. > > 7. Why do "schema" modification operations not produce an IDBTransactionEvent > > and instead produce IDBSuccessEvent? As already discussed on the list a long > > time ago, it is necessary to perform such operations in an explicit > > transaction. > > Hmm.. this is an interesting question. Might be good to raise this on the list. > > One solution would be to require version changes if you want transactionality. > We could even require that schema modifications happen inside a version change > transaction. > > Another solution is to add a 3rd mode, on top of READ and READ_WRITE which > allows for schema modifications and only allow schema modifications inside such > a transaction. setVersion would of course create such a transaction as well. > > I think I like the latter idea the best. The last time we discussed the semantics of setVersion you (and I) argued that setVersion should err on the side of making versioning easy for developers at the expense of it being a bit heavy handed (i.e. closing open connections and locking the world) because advanced apps could implement all the logic themselves if they wanted to. Neither of these options seem to be compatible with that concept (or Nikunj's vision for setVersion) though, so I don't think they'll work. Yeah, we probably need to bring this up on list.
I filed bug 10052 on getting atomic schema changes specified using setVersion
Any update on these changes being made to the spec? Maybe Andrei should take a shot at moving this forward?
I'd actually also be happy to submit a patch to the spec if that would help?
(In reply to comment #6) > I'd actually also be happy to submit a patch to the spec if that would help? I am happy to do the changes. Nikunj, are you ok with that? Jonas, if you already have a patch, please send it over. Else I can do the changes myself.
I don't have a patch, so go ahead and write one up.
Fixed in http://dvcs.w3.org/hg/IndexedDB/rev/f05d8668e4ac There may be errors / things I got wrong. I think we should open separate bugs for such problems.