Re: [IndexedDB] Current editor's draft

On Fri, Jul 9, 2010 at 12:50 PM, Nikunj Mehta <nikunj@o-micron.com> wrote:
>
> On Jul 10, 2010, at 12:29 AM, Jonas Sicking wrote:
>
>> On Fri, Jul 9, 2010 at 11:05 AM, Nikunj Mehta <nikunj@o-micron.com> wrote:
>>> We would not make dynamic transactions be the default since they would
>>> produce more concurrency than static scoped transactions, correct?
>>> On Jul 7, 2010, at 12:57 PM, Jonas Sicking wrote:
>>
>> I'm not sure I understand the question. We would use separate
>> functions for creating dynamic and static transactions so there is no
>> such thing as "default".
>
> The point is that we are talking of leaving out dynamic scope in v1, while, in the same vein, talking of making READ_ONLY the default _because_ it produces "good" performance. That is, IMHO, contradictory.

I think you are using flawed logic. Just because I want to remove one
feature that can be used to increase performance doesn't mean that I
hate performance and want to design all other features to be as slow
as possible.

I'm not arguing for removing dynamic transactions because I don't care
about performance. I'm arguing for removing dynamic transactions
because I think it's too hard for authors to use them correctly.

I absolutely care about performance, that is why I think we should use
READ_ONLY as default.

>>> Unless we're planning on making all
>>> transactions dynamic (I hope not), locks have to be grabbed when the
>>> transaction is created, right? If a transaction is holding a READ_ONLY
>>>
>>> lock for a given objectStore, then attempting to open that objectStore
>>>
>>> as READ_WRITE should obviously fail. Consecutively, if a transaction
>>>
>>> is holding a READ_WRITE lock for a given objectStore, then opening
>>>
>>> that objectStore as READ_ONLY doesn't seem to have any benefit over
>>>
>>> opening it as READ_WRITE. In short, I can't see any situation when
>>>
>>> you'd want to open an objectStore in a different mode than what was
>>>
>>> used when the transaction was created.
>>>
>>> Finally, I would stronly prefer to have READ_ONLY be the default
>>>
>>> transaction type if none is specified by the author. It is better to
>>>
>>> default to what results in higher performance, and have people notice
>>>
>>> when they need to switch to the slower mode. This is because people
>>>
>>> will very quickly notice if they use READ_ONLY when they need to use
>>>
>>> READ_WRITE, since the code will never work. However if people use
>>>
>>> READ_WRITE when all they need is READ_ONLY, then the only effect is
>>>
>>> likely to be an application that runs somewhat slower, when they will
>>>
>>> unlikely detect.
>>>
>>> This approach is also likely to cause exceptions upon put, remove, and add.
>>>
>>> I would prefer to not cause exceptions as the default behavior.
>>>
>>> If we use READ_WRITE as default behavior then it's extremely likely
>>> that people will use the wrong lock type and not realize. The downside
>>> will be that sites will run less concurrently, and thus slower, than
>>> they could.
>>>
>>> All along our primary objective with IndexedDB is to assist programmers who
>>> are not well versed with database programming to be able to write simple
>>> programs without errors. By that token, reducing the effort required for
>>> their use of IndexedDB seems to be the primary criteria and not great
>>> concurrency.
>>
>> As far as I can see this does not significantly complicate
>> development.
>
> This seems to be conveniently justified. A strict interpretation of the objective would not require the programmer to specify READ_WRITE even though that involves less mental (cognitive) and physical (typing) effort.

I simply don't use as strict interpretation of the objective of
simplifying development. Not every single decision we make will come
down in favor of what makes a simpler API.  Every decision we make is
a judgement call as there are advantages and disadvantages with
everything. I enumerated those advantages and disadvantages above and
I think think the advantages of using READ_ONLY are stronger.

>> In fact, in the process of writing test cases I have
>> several times forgotten to specify lock type. For the cases when I
>> needed a READ_WRITE lock, the code didn't work.
>
> It should have worked right the first time. Why wait for a programmer to find out why their code didn't work?

We can't ever prevent all mistakes. My point is that this mistake did
not meaningfully affect my ability to write working code.

I think we simply have to agree to disagree. Based on that, I'm
curious to know what other people think. So far it seems like mozilla
and google has come out in favor of using READ_ONLY as default.

/ Jonas

Received on Saturday, 10 July 2010 16:01:26 UTC