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

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
>