Re: [IndexedDB] Numeric constants vs enumerated strings

Also note that however painful an API change may seem now, it will only get
more painful the longer it is put off.

- James
On Feb 27, 2012 7:50 AM, Odin Hørthe Omdal <odinho@opera.com> wrote:

> I agree on the values. +1
>
> --
> Sent from my N9, excuse the top posting
>
> On 27.02.12 16:17 Jonas Sicking wrote:
> On Mon, Feb 27, 2012 at 1:44 PM, Odin Hørthe Omdal <odinho@opera.com>
> wrote:
> > On Sat, 25 Feb 2012 00:34:40 +0100, Israel Hilerio <
> israelh@microsoft.com>
> > wrote:
> >
> >> We have several internal and external teams implementing solutions on
> >> IndexedDB for IE10 and Win8.  They are looking for a finalized spec
> sooner
> >> than later to ensure the stability of their implementations.  Every
> time we
> >> change the APIs, they have to go back and update their implementations.
> >>  This activity sets them back and makes them loose confidence in the
> >> platform.
> >
> >
> > Hmmmm...
> >
> > If you implement the fallback that Sicking mentioned, just changing the
> > value of the e.g. IDBTransaction.READ_WRITE from 1 to "read-write" (or
> > whatever we'll choose to call it), then all that code will continue to
> work.
> >
> > It can be treated like an internal change. All the code I've seen from
> > Microsoft so far has used the constants (which is how it's supposed to be
> > used anyway) - so updating then won't be necessary.
> >
> >
> > This is a change for the huge masses of people which will come after us
> and
> > *not* be as wise and just input 1 or 2 or whatever that doesn't tell us
> > anything about what the code is doing.
> >
> > IMHO it's a very small price to pay for a bigger gain.
>
> Israel,
>
> I sympathize and definitely understand that this is a scary change to
> make so late in the game.
>
> However I think it would be a big improvement to the API. Both from
> the point of view of usability (it's a lot easier to write "readwrite"
> than IDBTransaction.READ_WRITE) and from the point of view of
> consistency with most other JS APIs that are now being created both
> inside the W3C and outside it.
>
> As has been pointed out, this change can be made in a very backwards
> compatible way. Any code which uses the constants would continue to
> work just as-is. You can even let .transaction() and .openCursor()
> accept numeric keys as well as the string-based ones so that if anyone
> does db.transaction("mystore", 2) it will continue to work.
>
> The only way something would break is if someone does something like
> "if (someRequest.readyState == 2)", but I've never seen any code like
> that, and there is very little reason for anyone to write such code.
>
>
> To speed up this process, I propose that we use the following values
> for the constants:
>
> IDBDatabase.transaction() - mode: "readwrite", "readonly"
> *.openCursor() - direction: "next", "nextunique", "prev", "prevunique"
> IDBRequest.readyState: "pending", "done"
> IDBCursor.direction: same as openCursor
> IDBTransaction.mode: "readwrite", "readonly", "versionchange"
>
> / Jonas
>
>