Yes! I would love to make this change. This is my main peeve with the API as it stands.
I even think that implementations could remove support for the numbers by keeping the constants but have them defined to return string values. I.e. db.transaction(["store"], IDBTransaction.READ_WRITE); would continue to work and is the usage pattern that I've seen in all code that I've looked at. Yes, the read-only attributes would change, but like Joshua I've never seen code use those so far. / Jonas On Wed, Feb 22, 2012 at 6:02 PM, Joshua Bell <jsb...@chromium.org> wrote: > On Wed, Feb 22, 2012 at 4:57 AM, Odin Hørthe Omdal <odi...@opera.com> wrote: >> >> I propose that we change the numeric constants to enumerated strings in >> the IndexedDB spec. >> >> Reasoning is echoing the reasoning that came up for WebRTC: >> >> <http://lists.w3.org/Archives/Public/public-script-coord/2012JanMar/0166.html> > > ... >> >> >> So. What do you think? :-) > > > I don't have strong feelings about this proposal either way. Ignoring the > *Sync APIs, this would involve changing: > > Methods: > IDBDatabase.transaction() - mode > IDBObjectStore.openCursor() - direction > IDBIndex.openCursor() - direction > IDBIndex.openKeyCursor() - direction > > Attributes (read-only): > IDBRequest.readyState > IDBCursor.direction > IDBTransaction.mode > > During a transition period, implementations of the methods could take either > a number or a string. The attributes are not so easy; it would be a breaking > change. Fortunately, those attributes are generally informative rather than > critical for app logic (at least, in the code I've seen), so the impact is > likely to be low. JS authors could check for both values (e.g. > request.readyState === IDBRequest.DONE || request.readyState === "done"), > just as authors must work around implementation differences today. So IMHO > it's plausible to make this change with little impact. >
