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

Re: [IndexedDB] Computed indexes

From: Jeremy Orlow <jorlow@chromium.org>
Date: Thu, 24 Jun 2010 15:54:56 +0100
Message-ID: <AANLkTikA_0ZNud7zj5oCX2QKjcbhnWFRtMXlooFQ02Pe@mail.gmail.com>
To: Shawn Wilsher <sdwilsh@mozilla.com>
Cc: Jonas Sicking <jonas@sicking.cc>, Webapps WG <public-webapps@w3.org>
On Thu, Jun 24, 2010 at 3:48 PM, Shawn Wilsher <sdwilsh@mozilla.com> wrote:

>  On 6/24/2010 7:01 AM, Jeremy Orlow wrote:
>
>> So what your proposing is that the keyPath would essentially be a string
>> of
>> the body of a function which runs for every index (on that objectStore)
>> for
>> every value inserted into that object store?  This seems like half way
>> between the eval-like idea I mentioned earlier.  It certainly seems to
>> have
>> advantages for complex keyPaths, but I'm still not so hot on having
>> boilerplate/assumptions (like needing "return" and assuming "value" is
>> present) present in every single keyPath.  Especially when the use cases
>> (while important) don't seem to be the common case.  (In fact, can you
>> even
>> do this in SQL?  If not, I think it's pretty strong evidence against
>> needing
>> to do arbitrary calculations in a keyPath.)
>>
> You can do something like this with triggers I think.
>

Triggers are actually a feature people within Google have asked me for.
 Such a thing would be useful for more than just computed indexes but would
likely be more heavyweight.  As far as I can tell, a trigger that fires on
changes to an objectStore would be enough to implement this feature
yourself.  We should probably look at general purpose triggers along side
these other keyPath proposals.


>
> Cheers,
>
> Shawn
>
>
Received on Thursday, 24 June 2010 14:55:48 GMT

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