Re: [IndexedDB] Reason for aborting transactions

On Wed, Feb 9, 2011 at 5:54 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Wed, Feb 9, 2011 at 5:43 PM, Jeremy Orlow <jorlow@chromium.org> wrote:
> > On Wed, Feb 9, 2011 at 5:37 PM, ben turner <bent.mozilla@gmail.com>
> wrote:
> >>
> >> > Normal exceptions have error messages that are not consistient across
> >> > implementations and are not localized.  What's the difference?
> >>
> >> These messages aren't part of any exception though, it's just some
> >> property on a transaction object. (None of our DOM exceptions, IDB or
> >> otherwise, have message properties btw, they're only converted to some
> >> message if they make it to the error console).
> >>
> >> > For stuff like internal errors, they seem especially important.
> >>
> >> You're thinking of having multiple messages for the INTERAL_ERROR_ABORT
> >> code?
> >
> > I think that'd be ideal, yes.  Since internal errors will be UA specific,
> > string matching wouldn't be so bad there.
> > If no one likes this idea, I'm happy hiding away the message in some
> > webkitAbortMessage attribute so it's super clear it's just us who
> implements
> > this.  (Speaking of which, maybe you guys should do that with getAll.)
>
> We'll definitely put getAll under a vendor prefix once we drop the
> "front door" prefix on .indexeddb.
>
> I'm with Ben here. I'd prefer to hide the message away under a vendor
> prefix (either now or once you drop the front door one) for now to
> gather feedback on how it'll be used.
>

It's common for people to do something like this:
indexeddb = indexeddb || moz_indexedDB || mozIndexedDB || webkitIndexedDB;
and then pretty much ignore which vendor's implementation they're using from
then on whenever possible, so I think it's worth doing a prefix on every
level of vendor specific stuff.  So we'll definitely use a prefix for the
abort message.  And I'd encourage you to do the same with getAll if you can
before FF4 ships.

J