Re: [IndexedDB] Current editor's draft

  On 7/9/2010 11:05 AM, Nikunj Mehta wrote:
> We would not make dynamic transactions be the default since they would produce more concurrency than static scoped transactions, correct?
I'm still of the opinion that dynamic transactions are a bad idea 
because it's too easy to hold a transaction open for a long period of 
time, making it easy for programmers to write incorrect/buggy code.

> 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.
Er, I thought we were targeting libraries but still wanted this to be 
simple to use.  Regardless, allowing for more concurrency doesn't hurt 
ease of use in any of what we've discussed so far (as far as I can tell).

>> Another downside is that authors should specify lock-type
>> more often, for optimal performance, if we think that READ_ONLY is
>> more common.
> You haven't provided any evidence about this yet.
I can assert that all the demos I've written (admittedly not many), 
simply reading from the database has been far more common than writing 
to it.  It's pretty much "write data in" but then do all operations on 
the local database.

> It is quite common in various languages to specify as a performance or 
> safety hint when someone desires a shared lock and use a read-write 
> version by default.
You seem to have contradictory statements here.  Earlier you argued that 
"reducing the effort required for their [programmers] use of IndexedDB 
seems to be the primary criteria", but having them to read and know 
performance or safety hints seems to me like we are making the API more 
complicated.  Having simple clear API calls with sensible error messages 
on misuse is far better than having an API that you can use one way (the 
most common way) but would be more efficient if you use it another way.

> For all we know, programmers would lock the entire database when they create a transaction. If dynamic transactions appear to be a non-v1 feature, then READ_ONLY being default appears out of place.
You asked Jonas for data backing up his claims, and now I'm going to ask 
the same of you.  It's been my experience and Ben Turner's experience 
that defaulting to READ_ONLY results in less code being written using 
this API.  Reads are far more common than writes (in databases in 
general, I think although edge cases certainly exist), so it makes sense 
to make that the default.

Cheers,

Shawn