[whatwg] Database storage API and argument type conversion

[Aaron Boodman]

On Thu, Apr 10, 2008 at 9:34 AM, Timothy Hatcher <timothy at apple.com> wrote:
> Converting an object to a string has a very defined path in JavaScript,
> toString is called. Perhaps the spec should mention toString.
>
> Marking the query as bogus seems wrong, since the JavaScript language is
> very lenient about types and implicit type conversions when needed. Implicit
> conversion to strings is what any proficient JavaScript author would expect
> to happen. I don't see any reason to make the storage spec behave
> differently.

So, we have some experience with this, having built several large
applications using an earlier version of the database API. Our current
implementation does coerce to string (we had the same initial
assumption as you), and having learned our lesson, we would like to
fix this in v2.

Here are a couple reasons why we would like to make this more strict:

1) There are lots of strange edge cases. SQLite does not support
boolean. Would you coerce it to a string? That means that if you
insert <false> and then select it, you get back something that
evaluates to <true>. Similar problem for <undefined>. Maybe a more
sensible coercion for these two types would be to int, but it seems
weird to make arbitrary distinctions for some popular input types, and
you're still losing  information.

2) Permanence. Coercion is a nice convenience most of the time in JS,
but I think with a permanent store, the damage you can do accidentally
goes up and warrants more care. An author probably will not find out
that he accidentally coerced undefined to string until long after the
damage has been done. It may be difficult to fix the data
retroactively. It doesn't seem worth the convenience to me. We
actually tried to fix this bug a little while after launch and found
non-Google applications in the wild accidentally storing <undefined>.
So this is a real concern for us.

3) Forward compatibility. If an implementation allows all valid js
types and coerces unsupported ones to supported ones, then it can
never add supported types. This is bad for implementors.

So for all these reasons, the Gears team will probably not be
implementing coercion in our implementation of the HTML5 database
spec. I'm not sure whether this belongs in the spec (it is tied to
SQLite details), but I think it is something vendors should keep in
mind, and it would be nice if we aligned on.


- a