> On 26 Mar 2011, at 10:14 AM, Nikunj Mehta wrote:
>
> What is the minimum that can be in IDB? I am guessing the following:
>
> 1. Sorted key-opaque value transactional store
> 2. Lookup of keys by values (or parts thereof)
Yes, this is what we need. In programmer speak: objects (opaque strings), sets
(hash indexes), sorted sets (range indexes).
> I know of no efficient way of doing callbacks with JS. Moreover, avoiding
> indices completely seems to miss the point.
Callbacks are unnecessary. This is what you would want to do as a developer
using the current form of IDB:
objectStore.putObject({ name: "Joran", emails: ["[email protected]",
"[email protected]"] }, { id: 'arbitraryObjectIdProvidedByTheApplication',
indexes: ["[email protected]", "[email protected]", "name=Joran"]
});
IDB would then store the user object using the id provided by the application,
and make sure it's referenced by this id in the "[email protected]",
"[email protected]", "name=Joran" index references provided (creating
these indexes along the way if need be). The application is responsible for
passing in the extra "id" and "indexes" options to putObject.
Supporting range indexes would be a question of expanding the above to let the
developer pass in a sort score along with the index reference.
> Next, originally, I also had floated the idea of application managed indices,
> but implementors thought of it as cruft.
I can understand how application managed indices would lead to less work on the
part of the spec committee. There seems to be some perverse human
characteristic that likes to make easy things difficult. Ships will sail around
the world but the Flat Earth Society will flourish.
> I, for one, am not enamored by key paths. However, I am also morbidly aware
> of the perils in JS land when using callback like mechanisms. Certainly, I
> would like to hear from developers like you how you find IDB if you were to
> not use any createIndex at all. Or at least that you would like to manage
> your own indices.
I am begging to be able to manage my indices. I know my data. I do not want to
use any createIndex to declare indexes in advance of when I may or may not use
them. What advantage would that give me? I want to create/update indexes only
when I put or delete objects and I want to have control over which indexes to
update accordingly. With one small change to the putObject and deleteObject
interfaces, in the form of the "indexes" option, we can make that possible.
We need these primitives in IDB: opaque strings, sets, sorted sets. Ideally,
IDB need simply store these things and provide the standard interfaces (see
Redis) to them along with a transactional mechanism. That's the perfect
low-level API on which to build almost any database wrapper.
