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

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.

So there are two situations when the result is "not available".

* After success/error has fired, but the "other" property is accessed.
* Before either success or result has fired.

I think generally avoiding throwing exceptions is a good thing. So for
.errorCode I would say returning unidentified or 0 is the way to go.
The latter is possibly more consistent with how other DOM APIs behave
since they tend to return a specific type. The former might be more
javascripty. I don't think it matters much as long as people can do

if (!req.errorCode) {
  ...assume success...
}

In the latter case it might be consistent with the rest of indexedDB
to throw NOT_ALLOWED_ERR. But going with "don't throw errors", it
might be better to returning 0/undefined. But it does seem like a
pretty bad bug if you do access these properties before having a
result. So maybe exception is in fact better here.

/ Jonas

>>
>>    attribute any result;
>>    attribute unsigned long errorCode;
>>    attribute DOMObject source;
>>    attribute IDBTransaction transaction;
>>
>>    const unsigned short LOADING = 1;
>>    const unsigned short DONE = 2;
>>    readonly attribute unsigned short readyState;
>>
>>             attribute Function       onsuccess;
>>             attribute Function       onerror;
>> };

Received on Friday, 11 February 2011 02:27:05 UTC