> transactions - Also should be optional. Vital to complex apps, but totally
> > not necessary for many.. there should be a default transaction, like
> > db.objectStore("foo").get("bar")
>
> I disagree. This would have made it too trivial to create pages that
> have race conditions. I.e. people would write code like:
>
> db.objectStore("foo").get("bar").onsuccess = function(e) {
> db.objectStore("foo").set("bar", e.target.result + 1)
> }
>
> without realizing that that contains a race condition.
>
> Its always possible for users to hang themselves - the web platform has
lots of rope. I could name a dozen gotchas like that in the JavaScript
language alone. The fact that we introduced shared workers introduces a
whole mess of issues like that. Not to criticize either - I think its just
something that happens as you introduce more flexible capabilities into the
platform.
In the above example, you could approach this with automatic transactions -
all operations that run in the callback of another IDB operation run in the
same transaction. So the set() and the get() are in the same transaction.
When you need explicit transactional control then you use the transaction()
API.
> > transaction scoping - even when you do want transactions, the api is just
> > too verbose and repetitive for "get one key from one object store" -
> > db.transaction("foo").objectStore("foo").get("bar") - there should be
> > implicit (lightweight) transactions like db.objectStore("foo").get("bar")
>
> We used to have this exact syntax, but it got everyone confused about
> what how the implicit transaction actually worked.
>
> This is surprising to me - *shrug* - I assume it was like the automatic
transactions I mentioned above.
>
> > named object stores - frankly, for many use cases, a single objectStore
> is
> > all you need. a simple db.get("foo") would be sufficient. Simply naming a
> > "default" isn't bad - whats bad is all the onupgradeneeded scaffolding
> > required to create the objectstore in the first place.
>
> I think we should do this as part of a simple API. Similar to something
> like
>
> https://github.com/slightlyoff/async-local-storage
>
>
Yes! I mean that's kind of where this conversation took off... I just don't
think there should be an obvious distinction between "the API with the
transactions and versions" and "the one without." - if anything presenting
them in a unified fashion allows for developers to migrate as they need
individual features (Transactions, versions, etc)
Alec