Re: [IndexedDB] Design Flaws: Not Stateless, Not Treating Objects As Opaque

On 31 March 2011 17:41, Jonas Sicking <jonas@sicking.cc> wrote:

> On Thu, Mar 31, 2011 at 1:32 AM, Joran Greef <joran@ronomon.com> wrote:
> > On 31 Mar 2011, at 9:53 AM, Jonas Sicking wrote:
> >
> >> I previously have asked for a detailed proposal, but so far you have
> >> not supplied one but instead keep referring to other unnamed database
> >> APIs.
> >
> > I have already provided an adequate interface proposal for putObject and
> deleteObject.
>
> That is hardly a comprehensive proposal, but rather just one small part of
> it.
>

I wanted to make a few comments about these points :-


>
> I do really think the idea of not having the implementation keep track
> of the set of indexes for a objectStore is a really interesting one.
> As is the idea of not even having a set set of objectStores. However,
> there are several problems that needs to be solved. In particular how
> do you deal with collations?
>

no indexes, no object stores... well I for one prefer the
"validate_object_store", "validate_index" approach, in that it can hide
statefullness if necessary (like I do with RelationalDB) whilst presenting a
stateless API. It also keeps the size of the put statements down.


>
> I.e. we have concluded that there are important use cases which
> require using different collations for different indexes and
> objectStores. Even for different indexes attached to the same
> objectStore.
>
> Additionally, if we're getting rid of setVersion, how do we expect
> pages dealing with the (application managed) schema changing while the
> page has a connection open to the database?
>

1 - there is no schema
2 - dont allow it to change whilst the database is open

In reality a schema is implicitly tied to a code version. In other words the
source code of the application assumes a certain schema. If the assumed
schema and the schema in the DB do not match things are going to go very
wrong very quickly. Schema changes _always_ accompany code changes
(otherwise they are not schema changes just data changes). As such they
never happen when a DB is open. The way I handle this in RelationalDB, by
validating the actual schema against the source-code schema in the db-open
(actually the method is called validate), is probably the best way to handle
this. If the database does not exist we create it according to the schema.
If it exists we check it matches the schema. If there is a difference we see
if we can 'upgrade' the database automatically (certain changes like adding
a new column with a default value can be done automaticall), if we cannot
automaticall upgrade, we exit with an error - as allowing the program to run
will result in corruption of the data already in the database. At this point
it is up to the application to figure out how to upgrade the database (by
opening one database with an old schema and another with a new schema)...
There is not point in ever allowing a database to be opened with the wrong
schema.


> So pretty please, with sugar on top, please come up with a proposal
> for the full API rather than bits and pieces.
>
> And I should mention that I have as an absolute requirement that you
> should be able to specify collation by simply saying that you want to
> use "en-US" or "sv-SV" sorting. Using callbacks or other means is ok
> *in addition to this*, but callback mechanisms tend to be a lot more
> complex since they have to deal with the callback doing all sorts of
> evil things such as returning inconsistent results (think "return
> Math.random()"), or simply do evil things like navigate the current
> page, deleting the database, or modifying the record that is in the
> process of being stored.
>

The core API only needs to deal with sorting binary-blob sort orders. A
library wrapper could provide all the collation ordering goodness that
people want. For example RelationalDB will have to deal with sorting orders,
it does not need the browser to provide that functionality. In fact browser
provided functionality may limit what can be done in libraries on top.


>
> / Jonas
>
>

Cheers,
Keean.