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

On 31 Mar 2011, at 9:34 AM, Jeremy Orlow wrote:

> We have made an effort to understand other "contributions to the field".
> 
> I'm not convinced that these are "essential database concepts" and having personally spent quite some time working with the API in JS and implementing it, I feel pretty confident that what we have for v1 is pretty solid.  There are definitely some things I wouldn't mind re-visiting or looking at closer, possibly even for v1, but they all seem reasonable to study further for v2 as well.
> 
> We've spent a lot of time over the last year and a half talking about IndexedDB.  But now it's shipping in Firefox 4 and soon Chrome 11.  So realistically v1 is not going to change much unless we are convinced that what's there is fundamentally broken.
> 
> We intentionally limited the scope of v1, which is why we know there'll be a v2.  We can't solve all the problems at once, and the difficulty of speccing something is typically exponential to the size of the API.
> 
> Maybe a constructive way to discuss this would be to look at what use cases will be difficult or impossible to achieve with the current design?

Application-managed indices for starters. I would consider that to be essential when designing indexed key/value stores, and I would consider that to be the contribution made by almost every other indexed key/value store to date. If we have to use IDB the way FriendFeed used MySQL to achieve application-managed indices then I would argue that the API is in fact "fundamentally broken" and we would be better off with an embedding of SQLite by Mozilla.

Regarding "the difficulty of speccing something is typically exponential to the size of the API", if people want to build a Rube Goldberg device then they must deal with the spec issues of that.

If we were provided with the primitives for an indexed key/value store with application-managed indices (as Nikunj suggested at the time), we would have been well out of the starting blocks by now, and issues such as "computed indexes", "indexing array values" etc. would have been non-issues.

Summary:

1. There's a problem.
2. It can still be fixed with a minimum of fuss.
3. This requires an adjustment to the putObject and deleteObject interfaces (see previous threads).

Received on Thursday, 31 March 2011 08:38:39 UTC