If an exception is unhanded in an IDB event handler, we abort the
transaction. Should we continue firing the other handlers when this
happens, though? And should preventDefault prevent the abort?
J
On Tue, Feb 15, 2011 at 11:52 AM, David Grogan <dgro...@chromium.org> wrote:
>
>
> On Mon, Feb 14, 2011 at 11:15 PM, Jonas Sicking <jo...@sicking.cc> wrote:
>
>> On Mon, Feb 14, 2011 at 7:53 PM, Jeremy Orlow <jor...@chromium.org>
>> wrote:
>> > On Mon, Feb 14, 2011 at 7:36 PM, David Grogan <dgro...@chromium.org>
>> wrote:
>> >>
>> >>
>> >> On Thu, Feb 10, 2011 at 5:58 PM, Jeremy Orlow <jor...@chromium.org>
>> wrote:
>> >>>
>> >>> On Thu, Jan 27, 2011 at 5:14 PM, Jonas Sicking <jo...@sicking.cc>
>> wrote:
>> >>>>
>> >>>> On Wed, Jan 26, 2011 at 11:47 AM, Jeremy Orlow <jor...@chromium.org>
>> >>>> wrote:
>> >>>> > What's the current thinking in terms of events that we're firing?
>> I
>> >>>> > remember we talked about this a bit, but I don't remember the
>> >>>> > conclusion and
>> >>>> > I can't find it captured anywhere.
>> >>>> > Here's a brain dump of the requirements as I remember them:
>> >>>> > * Everything should have a source attribute.
>> >>>> > * Everything done in the context of a transaction should have a
>> >>>> > transaction
>> >>>> > attribute. (Probably even errors, which I believe is not the
>> current
>> >>>> > case.)
>> >>>> > * Only success events should have a result.
>> >>>> > * Only error events should have a code and a message....or should
>> they
>> >>>> > just
>> >>>> > have an error attribute which holds an IDBDatabaseError object?
>> (If
>> >>>> > it's
>> >>>> > the former, then do we even need an interface for IDBDatabaseError
>> to
>> >>>> > be
>> >>>> > defined?)
>> >>>> > * IIRC, Jonas suggested at some point that maybe there should be
>> >>>> > additional
>> >>>> > attributes beyond just the source and/or objects should link to
>> their
>> >>>> > parents. (The latter probably makes the most sense, right? If so,
>> >>>> > I'll bug
>> >>>> > it.)
>> >>>> > Is there anything I'm missing?
>> >>>> > As far as I can tell, this means we need 5 events: an IDBEvent
>> (with
>> >>>> > source)
>> >>>> > and then error with transaction, error without, success with, and
>> >>>> > success
>> >>>> > without. That seems kind of ugly though.
>> >>>> > Another possibility is that we could put a transaction attribute on
>> >>>> > IDBEvent
>> >>>> > that's null when there's no transaction. And then error and
>> success
>> >>>> > would
>> >>>> > have their own subclasses. To me, this sounds best.
>> >>>> > Thoughts?
>> >>>>
>> >>>> Actually, I was proposing something entirely different.
>> >>>>
>> >>>> IDBRequest should look like this:
>> >>>>
>> >>>> interface IDBRequest : EventTarget {
>> >>>
>> >>> For each, what do we do when it's not available? Throw exception?
>> >>> Return undefined? Null? Particularly in the errorCode case, it's
>> not
>> >>> clear to me what the right thing to do is.
>> >>>
>> >>
>> >> How do IDBVersionChangeEvent and its version attribute fit in to this
>> new
>> >> model? Should we add a nullable version attribute to IDBRequest and
>> let the
>> >> function handling a blocked event check event.target.version? Could we
>> add
>> >> a version attribute just to IDBVersionChangeRequest?
>> >
>> > Adding a "newVersion", "nextVersion", or something similar to
>> > IDBVersionChangeRequest seems like the best answer to me. Simply adding
>> > "version" to it seems kind of confusing though.
>>
>> Adding it to the request won't help as the versionchange event is
>> fired at other databases, not at the request.
>
>
> It's fired at the request if the version_change transaction is blocked
> because other connections to the database remain open after receiving
> versionchange events, but I see what you mean.
>
>
>> Adding it to the request
>> is also not needed since the new version isn't something that is the
>> result of the request, it's something you specify when creating the
>> request.
>>
>> I think we can leave IDBVersionChangeEvent as it is, it's an entirely
>> different beast from success/error.
>>
>
> I'm on board with this.
>
>
>> / Jonas
>>
>
>
