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

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

/ Jonas

Received on Tuesday, 15 February 2011 07:16:52 UTC