[whatwg] executeSql API is synchronous

[Maciej Stachowiak]

On Sep 25, 2007, at 10:23 AM, Aaron Boodman wrote:

> On Sep 24, 2007 9:22 PM, Ian Hickson <ian at hixie.ch> wrote:
>> On Sun, 23 Sep 2007, Aaron Boodman wrote:
>>>
>>> db.executeSQL("select * from person where id = ?", [42],  
>>> function(result) {
>>>  // result is an array of objects
>>> });
>>>
>>> Another issue that this design addresses is that it avoid blocking  
>>> the
>>> UI for IO while iterating the results (all the results can be  
>>> iterated
>>> on a different thread).
>>
>> This is basically what the spec does now. There is some debate about
>> whether the results should actually be an Array or not though, to  
>> allow
>> for a lazy caching implementation if desired.
>
> I like the current specification of ResultSet:
> http://www.whatwg.org/specs/web-apps/current-work/#sqlresultset
>
> If you are not planning on changing it, you can stop reading now :)
> Otherwise, read on.

I agree that the actual I/O to the database should be done up front.  
However, it should be possible to make the conversion from SQLite's  
native data types to JavaScript datatypes lazy (such type conversion  
can have nontrivial cost, especially in bulk). To do that and get  
Array-like behavior, you need either a custom Array subclass, or a  
class that doesn't inherit the Array implementation but does have the  
Array prototype in its prototype chain. But the current spec rules  
this out by requiring the result to be a "native Array". Furthermore,  
being a "native Array" requires support for mutation, which again  
makes custom strategies involving lazy type conversion more challenging.

I would propose requiring that the row list object must have number- 
named properties for the contents, a read-only length property, and  
all Array prototype functions that do not modify the array somewhere  
in its prototype chain (this would include filter, forEach, map, but  
not sort or pop). I am not even sure the last part is necessary,  
because using Array.forEach is not *that* much more convenient than a  
for loop and is likely to be less efficient in many JS  
implementations. But if we want Array operations to be available, I'd  
suggest doing it in a way that does not constrain implementations to  
use a native Array.

Regards,
Maciej