Re: [IndexedDB] Two Real World Use-Cases

On Tue, Mar 1, 2011 at 7:34 AM, Joran Greef <joran@ronomon.com> wrote:

> I have been following the development behind IndexedDB with interest. Thank
> you all for your efforts.
>
> I understand that the initial version of IndexedDB will not support
> indexing array values.
>
> May I suggest an alternative derived from my home-brew server database
> evolved from experience using MySql, WebSql, LocalStorage, CouchDb, Tokyo
> Cabinet and Redis?
>
> 1. Be able to put an object and pass an array of index names which must
> reference the object. This may remove the need for a complicated indexing
> spec (perhaps the reason why this issue has been pushed into the future) and
> give developers all the flexibility they need.
>

You're talking about having multiple entries in a single index that point
towards the same primary key?  If so, then I strongly agree, and I think
others agree as well.  It's mostly a question of syntax.  A while ago we
brainstormed a couple possibilities.  I'll try to send out a proposal this
week.  I think this + compound keys should probably be our last v1 features
though.  (Though they almost certainly won't make Chrome 11 or Firefox 4,
unfortunately, hopefully they'll be done in the next version of each, and
hopefully that release with be fairly soon after for both.)


> 2. Be able to intersect and union indexes. This covers a tremendous amount
> of ground in terms of authorization and filtering.
>

Our plan was to punt some sort of join language to v2.  Could you give a
more concrete proposal for what we'd add?  It'd make it easier to see if
it's something realistic for v1 or not.

As you mention below, you can always do this in JS if necessary.  And
although I know it's not ideal, I think it's the right tradeoff in terms of
making it practical for browser vendors to get v1 out the door fairly fast.


> These two needs are critical.
>
> Without them, I will either carry on using WebSql for as long as possible,
> or be forced to use IndexedDb as a simple key value store and layer my own
> indexing on top.
>
> I am writing an email application and have to deal with secondary indexes
> of up to 4,000,000 keys. It would not be ideal to do intersects and unions
> on these indexes in the application layer.
>
> Regards
>
> Joran Greef
>