Re: [Bug 11348] New: [IndexedDB] Overhaul of the event model

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 <dgrogan@chromium.org> wrote:

>
>
> On Mon, Feb 14, 2011 at 11:15 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>
>> On Mon, Feb 14, 2011 at 7:53 PM, Jeremy Orlow <jorlow@chromium.org>
>> wrote:
>> > On Mon, Feb 14, 2011 at 7:36 PM, David Grogan <dgrogan@chromium.org>
>> wrote:
>> >>
>> >>
>> >> On Thu, Feb 10, 2011 at 5:58 PM, Jeremy Orlow <jorlow@chromium.org>
>> wrote:
>> >>>
>> >>> On Thu, Jan 27, 2011 at 5:14 PM, Jonas Sicking <jonas@sicking.cc>
>> wrote:
>> >>>>
>> >>>> On Wed, Jan 26, 2011 at 11:47 AM, Jeremy Orlow <jorlow@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
>>
>
>