Re: [IndexedDB] Compound and multiple keys

Getting pgsql people involved sounds a great idea. Having some more people
to argue for formalised and standardised database APIs like SQL, and
experience with relational operations and optimisation would be good (That
is an assumption on my part, but then they are writing PostgreSQL not
CouchDB). Do you know some people you could invite?

More generally though, I think BerkeleyDB would make a much better target
for IDB. I don't think it should be trying to be PostgreSQL or MySQL. I
think that implementing a good low-level API like BerkeleyDB that has enough
functionality to allow SQL to be implemented over the top.

The problem with trying to implement IDB on top of PostgreSQL is that IDB
has a very narrow interface, that does not support any of the powerful
features of pgsql. It would give you the worst of both. BDB would make a
much implementation.

Far more sensible would be to target the feature set of BDB for IDB, then
PostgreSQL could be re-implemented in JavaSctipt on top.  (a massive and
impractical task, but I am trying to express the relationship between high
level and low level database APIs).


If we wanted to go fully relational, and avoid the correctness problems with
string processing SQL commands, take a look at my relational library,
currently implemented on top of WebSQL but an IDB version is in the works:
https://github.com/keean/RelationalDB


Cheers,
Keean.


On 9 March 2011 04:10, Charles Pritchard <chuck@jumis.com> wrote:

>  On 3/8/2011 6:12 PM, Jeremy Orlow wrote:
>
> On Tue, Mar 8, 2011 at 5:55 PM, Pablo Castro <Pablo.Castro@microsoft.com>wrote:
>
>>
>> From: public-webapps-request@w3.org [mailto:public-webapps-request@w3.org]
>> On Behalf Of Keean Schupke
>> Sent: Tuesday, March 08, 2011 3:03 PM
>>
>> >> No objections here.
>> >>
>> >> Keean.
>> >>
>> >> On 8 March 2011 21:14, Jonas Sicking <jonas@sicking.cc><jonas@sicking.cc>wrote:
>> >> On Mon, Mar 7, 2011 at 10:43 PM, Jeremy Orlow <jorlow@chromium.org>
>> wrote:
>> >> > On Fri, Jan 21, 2011 at 1:41 AM, Jeremy Orlow <jorlow@chromium.org>
>> wrote:
>>
>> >> > After thinking about it a bunch and talking to others, I'm actually
>> leaning
>> >> > towards both option A and B.  Although this will be a little harder
>> for
>> >> > implementors, it seems like there are solid reasons why some users
>> would
>> >> > want to use A and solid reasons why others would want to use B.
>> >> > Any objections to us going that route?
>> >> Not from me. If I don't hear objections I'll write up a spec draft and
>> >> attach it here before committing to the spec.
>>
>>  Option A is pretty well understood, I like that one.
>>
>> For option B, at some point we had a debate on whether when indexing an
>> array value we should consider it a single key value or we should unfold it
>> into multiple index records. The first option makes it very similar to A in
>> that an array is just a composite value (it is quite a bit more painful to
>> implement...), the second option is interesting in that allows for new
>> scenarios such as objects with an array for tags, where you want to look up
>> by tag (even after doing options A and B as currently defined, in order
>> support multiple tags you'd need a second store that keeps the tags + key
>> for the objects you want to tag). Is there any interest in that scenario?
>>
>
>  Yes.  Once we're settled on this, I'm going to send an email on that.
>  :-)  Option b won't get in the way of my proposal.
>
>  J
>
>
> At some point, I really would like to get people from the PostgreSQL
> project involved with indexeddb.
>
> They have a wealth of experience to bring to the discussion. For the
> moment, like many "server-side" packages, they're at quite a distance from
> the w3.
>
> FWIW, pgsql is a perfectly valid 'host' for idb calls.
>
>
>