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

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.

/ Jonas

Received on Wednesday, 30 March 2011 22:58:10 UTC