W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2011

Re: [IndexedDB] Compound and multiple keys

From: Keean Schupke <keean@fry-it.com>
Date: Wed, 9 Mar 2011 11:02:51 +0000
Message-ID: <AANLkTimTm94TBG_F1S+TnghcLTFa3JWUMaw-Rq-jirOZ@mail.gmail.com>
To: Jeremy Orlow <jorlow@chromium.org>
Cc: Charles Pritchard <chuck@jumis.com>, Pablo Castro <Pablo.Castro@microsoft.com>, Jonas Sicking <jonas@sicking.cc>, "Tab Atkins Jr." <jackalmage@gmail.com>, Webapps WG <public-webapps@w3.org>
I have already said I have no specific concerns regarding this change. Its
difficult to predict problems that will emerge when people actually try and
use an API. That's why there are so many bad APIs out there. One way to
mitigate this risk is to look at well used existing APIs (in languages like
'c') to see what works well. Many people often write different APIs for the
same task, and the best win. I would look to existing winners (like BDB) for
guidance on the total API, as due to the standardisation process (and the
nature of web browsers) there is no opportunity for competition to choose
the best API. It would be nice if jsnode was more advanced, then there might
be many database API implementations in JavaScript we could look at to see
which are preferred and use as a starting point.

Looking at the requirements for IDB, BerkeleyDB would seem to be an ideal
candidate to port the API, its popular, widely used and has stood the test
of time, and is easy to use, and would be even easier in JavaScript with
garbage collection.


On 9 March 2011 09:41, Jeremy Orlow <jorlow@chromium.org> wrote:

> 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.
Received on Wednesday, 9 March 2011 11:03:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:16 UTC