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

On Wed, Mar 30, 2011 at 3:57 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> On Sat, Mar 26, 2011 at 1:14 AM, Nikunj Mehta <nikunj@o-micron.com> wrote:
>> What is the minimum that can be in IDB? I am guessing the following:
>> 1. Sorted key-opaque value transactional store
>> 2. Lookup of keys by values (or parts thereof)
>> #1 is essential.
>> #2 is unavoidable because you would want to efficiently manipulate values by
>> values as opposed to values by key.
>> I know of no efficient way of doing callbacks with JS. Moreover, avoiding
>> indices completely seems to miss the point. Yes, IDB can be used without key
>> paths and indices. When you do that, you would not have any headache of
>> setVersion since every version change either adds or removes an "object
>> store". Next, originally, I also had floated the idea of application managed
>> indices, but implementors thought of it as cruft.
>
> For what it's worth, I'm not sure anyone ever thought it was "cruft".
> The main problem, IMHO, was that it was underdefined. It also created
> a somewhat awkward API since even indexes which were not manually
> managed would have functions for explicitly managing them. (It also
> wouldn't help with the state issues that is raised in the original
> email in this thread).
>
> Anyhow, I do think that the idea of passing in index values at the
> same time as a entry is created/modified is an interesting idea. And I
> have said so in the past on this list. It's definitely something we
> should consider for v2.
>
> However this still wouldn't solve the state issue raised in this
> thread. The browser still keeps track of the set of objectStores. You
> could get rid of that by changing the APIs such that there isn't a set
> list of object stores. I.e. remove IDBDatabase.objectStoreNames,
> IDBDatabase.createObjectStore and IDBDatabase.deleteObjectStore and
> make IDBDatabase.transaction allow any object store names to be passed
> to it. This would let you "create" a new objectStore by simply
> starting a transaction which uses the new name and start storing data
> into it.
>
> But even then you still want the setVersion API. Otherwise the web
> page has no way of migrating stored data to a new schema. Even though
> the browser doesn't keep track of a schema, the app still does, and
> likely will want to change that from time to time.

Oh, and if we did this, I wouldn't really know how to support things
like collations. Neither if you did collations using built in sets of
locales (like in Pablo's recent proposal), nor if you used some sort
of callback to do collation.

/ Jonas

Received on Wednesday, 30 March 2011 23:02:53 UTC