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

RE: [IndexedDB] Proposal for async API changes

From: Pablo Castro <Pablo.Castro@microsoft.com>
Date: Thu, 20 May 2010 23:06:06 +0000
To: Jeremy Orlow <jorlow@chromium.org>, Shawn Wilsher <sdwilsh@mozilla.com>
CC: Jonas Sicking <jonas@sicking.cc>, Webapps WG <public-webapps@w3.org>
Message-ID: <F753B2C401114141B426DB383C8885E04DAD225A@TK5EX14MBXC128.redmond.corp.microsoft.com>
(still catching up on the rest of the long thread of API changes, will get back to that a bit later)

From: public-webapps-request@w3.org [mailto:public-webapps-request@w3.org] On Behalf Of Jeremy Orlow
Sent: Thursday, May 20, 2010 3:34 PM

>> >> On Thu, May 20, 2010 at 11:25 PM, Shawn Wilsher <sdwilsh@mozilla.com> wrote:
>> >> On 5/20/2010 7:34 AM, Shawn Wilsher wrote:
>> >> So far it's really just that joins are painful in IndexedDB. I'm working
>> >> on a blog post on this very topic though, and I'll be sure to point
>> >> everyone in this thread to it (I figure this is useful stuff to get out
>> >> to a wider audience).
>> >> And honestly, I thought that we had discussed joins on this list, but I only see a thread from Pablo mentioning it, but no real discussions. Should we start that?

>> Joins were actually in the original spec but taken out during the effort to simply the API greatly.  IIRC, the main reason why Nikunj took them out is that we believed you could fairly efficiently join yourself if you had 2 sorted lists and because we didn't see a simple way to do them without introducing a lot of API surface area or creating (or borrowing) some sort of syntax for the joins.  (Now that I think about it, though, maybe doing this is not that big of a leap from what we're going to need to do to spec keyPaths.  I'm starting to wonder if we need to rethink that as well....)

>> Anyway, the decision was made so long ago that maybe it's worth re-opening the discussion.  I'll hunt through my mail archives tomorrow and start a new thread with references to any original bits of info I can find.

My main concern with joins, besides API surface, was that in order to implement joins you need to choose an actual strategy. Depending on whether you have indexes or not and other circumstances you could choose to do range scans/lookups, a merge join, etc. So at least for fancier libraries this would only be of partial help, as they would probably want to do their own joins sometimes. 

I'm happy to explore again though. It's certainly the case that for simpler cases it might help users pull off tasks without depending on a library. I do wonder if we should try and land the async API first.

-pablo

J
Received on Thursday, 20 May 2010 23:06:41 GMT

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