Re: [IndexedDB] Numeric constants vs enumerated strings

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 <> wrote:
> On Wed, Feb 22, 2012 at 4:57 AM, Odin HÝrthe Omdal <> 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:
>> <>
> ...
>> 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.

Received on Thursday, 23 February 2012 00:28:25 UTC