Re: IndexedDB TPAC agenda

On Mon, Nov 1, 2010 at 5:13 AM, Jeremy Orlow <jorlow@chromium.org> wrote:
> 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....?

I'm lost as to what you're saying here. Could you elaborate? Are you
saying "index" when you mean "array" anywhere?

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

Agreed.

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

There is also the option to let the transaction finish. They should be
short-lived so it shouldn't be too bad.

>> * Error handling
>
> What do you mean by this?

How to handle exceptions in various places. Where (error) events
propagate. How does it relate to window.onerror. What happens if you
do/don't call preventDefault on the error event?

/ Jonas

Received on Monday, 1 November 2010 12:23:51 UTC