Re: [IndexedDB] Computed indexes

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