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

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 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?

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?

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.

/ Jonas

Received on Thursday, 31 March 2011 17:42:33 UTC