Re: [IndexedDB] Current editor's draft

  On 7/9/2010 12:50 PM, Nikunj Mehta wrote:
> 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.
Dynamic scope == dynamic transactions, correct?  Can you please 
elaborate on how dynamic transactions improve performance?

> 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.
FWIW, this isn't constructive.  Your argument also seems to assume that 
writes are more common than reads, which hasn't been my experience with 
this API.

> It should have worked right the first time. Why wait for a programmer to find out why their code didn't work?
Why make writing code with good performance characteristics the uncommon 
case?  We clearly have two different schools of thoughts here, and I'm 
not sure we are going to find a consensus...

> There are many ways to get performance improvement, including dynamic transactions, which you seem not to be favorable towards. I don't see why READ_ONLY should be given special treatment.
It's unclear to me why you think READ_ONLY is getting special treatment 
(or what that even means in this context).

> Various hints are used in SQL syntax, e.g., [1], to manage locks, a certain kind of B-tree behavior, or a level of isolation. These are all aimed at improving performance, but they are set as default behavior. My point is that expecting good performance from a single variable in database systems out of possibly hundreds is not all that helpful. It is also a slippery slope because it confuses performance with options. The database's job is to be fast at what it does, not play performance tricks using default values.
While I think this argument makes sense in some cases, I really don't 
feel like it applies at all in this situation.  Even the page you linked 
to says "Because the SQL Server query optimizer typically selects the 
best execution plan for a query..." which in most cases would be 
READ_ONLY (based on evidence the Mozilla team has from demos written).  
The default should represent the commonly used case.

> I don't know that we can make the right performance decisions for 
> people. What we can do is make things perform well and provide tools 
> to improve performance.
We aren't making performance decisions though; we are just picking the 
default to be the most commonly used option.  It just happens to be the 
one to allow more concurrency.

Cheers,

Shawn