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

On 31 March 2011 18:36, Jeremy Orlow <jorlow@chromium.org> wrote:

> On Thu, Mar 31, 2011 at 11:24 AM, Keean Schupke <keean@fry-it.com> wrote:
>
>> On 31 March 2011 18:17, Jeremy Orlow <jorlow@chromium.org> wrote:
>>
>>> On Thu, Mar 31, 2011 at 11:09 AM, Keean Schupke <keean@fry-it.com>wrote:
>>>
>>>> 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.
>>>>
>>>
>>> This is difficult if not impossible to do.  See previous threads on the
>>> matter.
>>>
>>> J
>>>
>>
>> I can find a lot of stuff on collation, but not a lot about why it could
>> not be done in a library. Could you summerise the reasons why this needs to
>> be core functionality for me?
>>
>
> Sorry, but that stuff is paged out of my brain.  Pablo, can you?
>
>
>> A library could chose to use an object store as meta-data to store the
>> collation orders that it is using for various indexes for example.
>>
>>
>> Cheers,
>> Keean.
>>
>>
>
>
Thanks would help me understand. As long as there is a way to turn default
collation off and just have a binary string sort order thats fine for my
needs.


Cheers,
Keean.