Re: [IndexedDB] Current editor's draft

On Fri, Jul 9, 2010 at 12:21 PM, Nikunj Mehta <nikunj@o-micron.com> wrote:
>>>>
>>>
>>> I don't think it's even possible with the current API since
>>> openTransaction() takes a list of objectStore names but a single mode.
>>
>> Indeed. We could allow static transactions to use different lock
>> levels for different objectStores, all specified when the
>> IDBTransaction is initially created. It's just a matter of syntax to
>> the IDBDatabase.transaction() function. However so far I've thought
>> that we should leave this for v2. But if people would feel more easy
>> about dropping dynamic transactions if we add this ability, then I
>> would be ok with it.
>
> From my examples, it was clear that we need different object stores to be opened in different modes. Currently dynamic scope supports this use case, i.e., allow mode specification on a per object-store basis. Therefore, unless we decide to de-support this use case, we would need to add this ability to static scope transactions if dynamic scope transactions go out of v1.

I don't see why you couldn't always open all needed objectStores in
READ_WRITE mode? Can you point to the specific function where this
wouldn't be possible?

>>>> If it is the case that specifying a mode when opening an objectStore
>>>> only makes sense on dynamic transactions, then I think we should only
>>>> expose that argument on dynamic transactions.
>>>>
>>>> Now that I understand your proposal better, I don't understand how
>>>> IDBTransaction.objectStore works for dynamically scoped transactions
>>>> in your proposal. It seems to require synchronously grabbing a lock
>>>> which I thought we wanted to avoid at all cost.
>
> See below.
>
>>>>
>>>
>>> This is rather confusing: is IDBTransaction::objectStore() creating an
>>> object store, now? If yes, then it must lock it synchronously. If it just
>>> returns an object store that was previously added to the transaction, what
>>> is the 'mode' parameter for?
>>
>> Looking at Nikunj's example code, it seems like you can request a new
>> objectStore to be locked using IDBTransaction.objectStore(). Not sure
>> if that is a bug or not though?
>
> That was a bug. For dynamic transactions, obtaining an object store would have to be asynchronous as it involves obtaining a lock.

Ok, so what happens if IDBTransaction.objectStore is called during a
dynamic transaction? Or if IDBDatabase.openObjectStore is called from
a static transaction? What if IDBDatabase.openObjectStore is called
from a static transaction using a objectStore name which wasn't locked
when the transaction was created?

I really think we need to separate the interfaces for dynamic and
static transactions and have the synchronous .objectStore only
available on static transactions, while the asynchronous
.openObjectStore needs to be available only on dynamic transactions.

> I also did not hear from you about explicit commits. Did that mean that you agree with that part of my proposal? There are several examples where it makes sense to explicitly commit, although it is automatic in some cases.

I haven't yet had time to analyze this. I wanted to do so before
commenting. I don't have time right now, but will do so tomorrow.

/ Jonas

Received on Saturday, 10 July 2010 01:27:58 UTC