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 <jsbell@chromium.org> wrote:
> On Wed, Feb 22, 2012 at 4:57 AM, Odin Hørthe Omdal <odinho@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.
>

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