Re: [Bug 11398] New: [IndexedDB] Methods that take multiple optional parameters should instead take an options object

On Tue, Dec 14, 2010 at 7:50 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Tue, Dec 14, 2010 at 8:47 AM, Jeremy Orlow <jorlow@chromium.org> wrote:
>
>> Btw, I forgot to mention IDBDatabase.transaction which I definitely think
>> should take an options object as well.
>
>
> Hmm.. I think we should make the first argument required, I actually
> thought it was until I looked just now. I don't see what the use case is for
> opening all tables.
>

FWIW I'm finding that the majority of the IndexedDB code I read and write
does indeed need to lock everything.  I'm also finding that most of the code
I'm writing/reading won't be helped at all by defaulting to READ_ONLY...


> In fact, it seems rather harmful that the syntax which will result in more
> lock contention is simpler than the syntax which is better optimized.
>

But you're right about this.  So, if we're trying to force users to write
highly parallelizable code, then yes the first arg probably should be
required.  But if we're trying to make IndexedDB easy to use then actually
the mode should probably be changed back to defaulting to READ_WRITE.

I know I argued for the mode default change earlier, but I'm having second
thoughts.  We've spent so much effort making the rest of the API easy to use
that having points of abrasion like this seem a bit wrong.  Especially if
(at least in my experience) the abrasion is only going to help a limited
number of cases--and probably ones where the developers will pay attention
to this without us being heavy-handed.


> This leaves two optional arguments, the second of which is likely very
> rarely going to be used. In fact, I wouldn't mind removing it entirely since
> it just seems like it risks causing race conditions. And it's technically
> syntax sugar since you can always use setTimeout and call .abort() manually.
>

Removing timeout SGTM.

J