- From: Chris Anderson <jchris@apache.org>
- Date: Fri, 15 Jan 2010 11:13:48 -0800
- To: public-webapps WG <public-webapps@w3.org>
Hi, I've been reading the new IndexedDB spec as published here: http://www.w3.org/TR/IndexedDB/ My first impression is that this simpler than WebSimpleDB, but not too simple. I'm happy to see detached readers being mentioned. There's one other piece of the concurrency story that could be useful. In section 3.2.2 Object Store Storage steps step 7: If the no-overwrite flag was passed to these steps and is set, and a record already exists with its key being key, then terminate these steps and set error code CONSTRAINT_ERR. I think it wouldn't add much complexity to use a compare-and-swap pattern, instead of a no-write-if-exists pattern. This would allow for better concurrency via optimistic updates, and look a lot like HTTP etags. It could be accomplished by allowing an object store to take a key-path for the update-token. Then subsequent updates could require that the key-path match. (Some additional complexity: we'd need the ability to check for a matching update-token, then change it, in a transaction). CouchDB uses an MVCC token that must match to allow updates. This allows us to avoid locking. But even more important is the parallels we have with HTTP Etags (if-match for idempotence, if-none-match for caching). The CouchDB style of MVCC can be accomplished by updates in a compare-and-swap transaction, so technically I can do what I want in the spec as it stands. But I still think the parallels to HTTP etags can be instructive. Chris -- Chris Anderson http://jchrisa.net http://couch.io
Received on Friday, 15 January 2010 19:14:21 UTC