W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2010

Re: [IndexedDB] Computed indexes

From: Jeremy Orlow <jorlow@chromium.org>
Date: Tue, 29 Jun 2010 09:59:18 +1000
Message-ID: <AANLkTik5XEZ-vEx0OU12RVo5I_DFcBc60k5egTjNRZic@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Webapps WG <public-webapps@w3.org>
On Tue, Jun 29, 2010 at 7:21 AM, Jonas Sicking <jonas@sicking.cc> wrote:

> I'm pretty convinced that complex indexes is something that people
> need to do. However it's entirely possible that simply using a
> separate objectStore is good enough for v1. More details below.
>
> >> Though maybe people can use separate objectStores which hold computed
> >> values. That might certainly be good enough for version 1. I'll have
> >> to think more about that.
> >
> > Hmmm....I'm not sure I follow.  Could you explain more thoroughly?
>
> To bring back an old example. Say that you're storing objects like
>
> { name: "Elvis", born: "January 8, 1935", died: "August 16, 1977" }
> { name: "Gustav III", born: "24 January 1746", died: "29 March 1792" }
> { name: "Benny Andersson", born: "16 December 1946" }
>
> and want to index on the age-at-death. What you'd do is that you set
> up a separate objectStore using the following calls:
>
> store = createObjectStore("AgeAtDeathStoreIndex", "name", false);
> store.createIndex("ageIndex", "age", false);
>
> When the above three objects are stored, you also store the following
> two object into the "AgeAtDeathStoreIndex" objecStore:
>
> { name: "Elvis", age: 42 }
> { name: "Gustav III", age: 46 }
>
> You can then easily search based on age at death by first looking
> something up in the ageIndex and then looking up the found name in the
> original objecStore. Something like:
>
> // only finds one person
> trans = db.transaction(["people", "AgeAtDeathStoreIndex"]);
>
> trans.objectStore("AgeAtDeathStoreIndex").index("ageIndex").get(42).onsuccess
> = function(e) {
>  trans.objectStore("people").get(e.value).onsuccess = function(e) {
>    alert(e.value.name + " was 42 at time of death");
>  }
> }
>
> This is certainly more work, but at least it avoids *forcing* us to
> put anything into v1 of IndexedDB.
>

Gotcha.  Yeah, this technique can be used to replace any use case for
explicitly managed indexes.  And, for that reason, I think we should just
get rid of them now.

As for whether we should have a feature to compute index keys via
a function: I think we should put it on it on the back burner for now, but
use your proposal as the starting when we re-examine it.  I'd like to do
this after there's a working implementation in the wild that developers can
play with so we can address the biggest pain points--rather than just going
on our intuition.  If this does get punted past v1, I'd definitely like to
see it addressed in v2 though.

J
Received on Tuesday, 29 June 2010 00:00:09 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:39 GMT