Re: IndexedDB TPAC agenda

On Mon, Nov 1, 2010 at 11:53 AM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Mon, Nov 1, 2010 at 4:40 AM, Jeremy Orlow <jorlow@chromium.org> wrote:
> > What items should we try to cover during the f2f?
> > On Mon, Nov 1, 2010 at 11:08 AM, Jonas Sicking <jonas@sicking.cc> wrote:
> >>
> >> > P.S. I'm happy to discuss all of this f2f tomorrow rather than over
> >> > email
> >> > now.
> >>
> >> Speaking of which, would be great to have an agenda. Some of the
> >> bigger items are:
> >>
> >> * Dynamic transactions
> >> * Arrays-as-keys
> >> * Arrays and indexes (what to do if the keyPath for an index evaluates
> >> to an array)
> >> * Synchronous API
> >
> > * Compound keys.
> > * What should be allowed in a keyPath.
>
> Aren't "compound keys" same as "arrays-as-keys"?
>

Sorry, I meant to say compound indexes.

We've talked about using indexes in many different ways--including compound
indexes and allowing keys to include indexes.  I assumed you meant the
latter....?


> * What should happen if an index's keyPath points to a property which
> doesn't exist or which isn't a valid key-value? (same general topic as
> "arrays and indexes" above)
>

We've talked about this several times.  It'd be great to settle on something
once and for all.


> * What happens if the user leaves a page in the middle of a
> transaction? (this might be nice to tackle since there'll be lots of
> relevant people in the room)
>

I'm pretty sure this is simple: if there's an onsuccess/onerror handler that
has not yet fired (or we're in the middle of firing), then you abort the
transaction.  If not, the behavior is undefined (because there's no way the
app could have observed the difference anyway).  The aborting behavior is
necessary since the user could have planned to execute additional commands
atomically in the handler.


> * Error handling


What do you mean by this?

J