Re: [IndexedDB] Compound and multiple keys

Keean/Charles:

I definitely think the more people involved the better, but let's not get
too hung up on the specifics of PostgreSQL, BDB, etc.  Our goal here should
be to make a great API for web developers while balancing practical
considerations like how difficult it'll be to implement and/or use
efficiently.

That said, I'm not understanding what your comments have to do with this
proposal.  Do you have specific concerns?

J

On Wed, Mar 9, 2011 at 12:55 AM, Keean Schupke <keean@fry-it.com> wrote:

> 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.
>>
>>
>>
>