Re: [IndexedDB] Closing on bug 9903 (collations)

On 3 May 2011 23:59, Aryeh Gregor <Simetrical+w3c@gmail.com> wrote:

> On Tue, May 3, 2011 at 10:56 AM, Keean Schupke <keean@fry-it.com> wrote:
> > Why does it need to be persisted? I would prefer the database to be
> > stateless. Obviously all users of the database need to use the same
> > function.
>
> And if they don't use exactly the same function, maybe due to a
> transient bug, the index is silently and permanently corrupted, until
> all affected rows happen to be updated again?  That doesn't sound like
> a good idea to me.
>
>
I thought only the app that created the db could open it (for security
reasons)... so it becomes the app's responsibility to do version control.
The comparison function is not going to change by itself - someone has to go
into the code and change it, when they do that they should up the revision
of the database, if that change is incompatible.

There is exactly the same problem with object properties. If the app changes
to expect a new property on all objects stored, then the app has to
correctly deal with the update.

There are two issues here:

1) doing things correctly - there is no problem here, providing the closure
works.

2) making things easy for the user - for me a simpler more predictable API
is better for the user. Having a function stored inside the database is bad,
because you cannot see what function might be stored in there... it might be
a function from a previous version of the code and cause all sorts of
strange bugs (which will only affect certain users with a certain version of
the function stored in their DB). By having the sort function in plain sight
in the source code it is visible and readable. Yes, there is a risk that the
code is changed and the order method is different from that in the DB, which
will cause breakage, but so can a function hidden in the database. Of the
two I would always choose to have everything clearly visible in the source
code where you can check it.


Cheers,
Keean.