Re: [IndexedDB] Two Real World Use-Cases

On 2 March 2011 12:09, Joran Greef <joran@ronomon.com> wrote:

> On 02 Mar 2011, at 1:31 PM, Jonas Sicking wrote:
>
> > I agree that we are currently enforcing a bit of schema due to the way
> > indexes work. However I think it's a good approach for an initial
> > version of this API as it covers the most simple use cases. Note that
> > the more complex use cases are still very possible by simply using a
> > separate objectStore as an index and manually add/remove things there.
> >
> > I still believe that using a function, which is persisted in the
> > database, is very doable. And yes, the function needs to be stateless
> > and it needs to be possible to change the set of functions which
> > manage the set of indexes associated with a given objectStore
> > (probably by simply allowing indexes to be created and removed, which
> > is already the case).
> >
> > / Jonas
>
> Thank you Jonas, I'm using your multi objectStore trick at the moment to
> store indexes.
>
> It just seems that the most direct way of doing all of this, would just be
> to let the application pass in the relevant index references when it makes
> put or delete calls. IDB is almost becoming a Rube Goldberg device trying to
> find other ways of doing this.
>
> The reason I bring it up, is because I just made this same change with my
> server database, which used to require schema knowledge, so it could compute
> indexes etc., and then I realized this could all be eliminated completely by
> just passing indexes per put and delete call.
>
> I really don't think IDB should try and dip it's toes into application
> state in the first place, let alone try and keep up with application state
> thereafter. What is the motivation for doing that? It's not absolutely
> necessary. It's an assumption that is bloating almost every part of the
> spec. It's not the killer feature of IDB, and it's getting in the way of
> things that could be, such as indexing and querying. If version 1 is done
> right, there will be no need for version 2. There's been a tremendous amount
> of discussion regarding IDB and people like yourself and Jeremy have
> certainly contributed massively, but I do get the feeling (as may you) that
> version 2 is becoming a stopover for things that have not been thought
> through completely, for which a solution is not yet clear, something's not
> right. I only say this from recently re-writing a database after making the
> same mistake.
>
>
>
Personally I think allowing multiple index entries for a single object
breaks referential transparency. I would have one index where objects are
indexed by a unique object ID, and another index object-ids are indexed by
email-address. I suspect this is what you are doing now?

To improve on this situation (and keep referential transparency) would
require multiple indexes on a single object (so you can have a unique
primary key (object-id), and a secondary index on email-address), but as I
said earlier you are then well on the way to re-inventing a relational
database. IMHO you are then better off implementing relations properly,
rather than producing something not entirely quite unlike a relational
database.

Cheers,
Keean.