Re: [IndexedDB] Compound and multiple keys

On Wed, Mar 16, 2011 at 9:01 AM, Joran Greef <joran@ronomon.com> wrote:
>> On 3/9/2011 09:45:51 Shawn Wilsher wrote:
>>
>> That makes sense since the original proposal was heavily based on BDB.
>> It's shifted a bit as we have made tweaks to improve it for the web.
>>
>> Cheers
>>
>> Shawn
>
> I agree. If I may add my two cents worth: one thing that IDB has not yet learned from BDB is statelessness. At the moment IDB requires a bit of application state to be mixed up in IDB (i.e. by predefining indexes as opposed to allowing the application to specify indexes to be modified when putting or deleting objects). So it's not a pure data+indexes store, it's actually a data+indexes+application state store. This is making IDB more complex than it needs to be and is making the IDB interface less powerful (things like compound keys etc. would already be possible if IDB were stateless). For instance, if IDB is to store application state, then the spec needs to define what happens when the application state changes. If IDB were stateless, this would not be necessary. After the web having had no options for offline storage for so many years, it is probably safe to say that web applications do not need help with things like migrations, pre-defined schemas or anything fancy or "helpful" like that, they just need a pure data+indexes solution (but they need this to be comprehensive: at least set operations supported on indexes, and indexes defined by the application when putting or deleting objects and NOT before). In my honest opinion, IDB is not yet there and from the discussions does not seem to be headed in that direction. It's trying to make unnecessary things easy when it really needs to be just a powerful low-level data store with first-class indexing. I'm not sure how many users of IDB are actively involved in this discussion, but after spending hours on it over the past few months, and having built databases over LocalStorage and WebSQL, as a real-world user, may I ask that these concerns begin to be addressed?

It seems like you are suggesting pretty big changes. The best way to
do this is likely to start a new thread (as the changes you are
suggesting isn't limited to "Compound and multiple keys"), and put a
draft proposal there.

It by no means has to be perfect (it took us a long time to polish IDB
into what it is today), but it needs to be more detailed than what you
are saying above.

Also, I should mention that time is running out on major changes. We
already have two database APIs, WebSQL and IDB, (three if you count
localStorage), so there both needs to be significant advantages over
the already existing APIs, and you would make yourself a favor by
acting fast as the other specifications are gaining momentum literally
by the day.

/ Jonas

Received on Wednesday, 16 March 2011 18:00:34 UTC