[whatwg] executeSql API is synchronous

On Tue, 25 Sep 2007, Maciej Stachowiak wrote:
> 
> 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.

On Tue, 25 Sep 2007, Aaron Boodman wrote:
> 
> Ah, that makes sense. A special purpose class for the rows property is 
> fine with me. I don't feel that strongly about forEach and friends.

Done (without the Array methods).


On Tue, 25 Sep 2007, Dimitri Glazkov wrote:
> 
> Speaking of forEach, what do you think of (pardon any syntax errors,
> writing straight into gmail window):
> 
> db.forEach("SELECT * FROM pages;", function(row) {
>     this.innerHTML += "<li><a href=\"" + row.url + "\">" + row.title +
> "</a></li>";
> }, document.getElementById("pages"))
> 
> and...
> 
> document.getElementById("pages").innerHTML = "<ul>" + db.map("SELECT *
> FROM pages", function(row) {
>     return "<li><a href=\"" + row.url + "\">" + row.title + "</a></li>"
> }).join("") + "</ul>";
> 
> Why expose rows collection at all?

I think the above API would be must less flexible to the author. What if 
you just want the third row or something?


On Fri, 5 Oct 2007, Scott Hess wrote:
> 
> If app developers, users, and browsers all agree that they want to run 
> some app with a substantial local database footprint, one could imagine 
> an accidental "select * from blog_postings_Ive_read" taking 2GB of 
> memory encoded as UTF-16.  Obviously this would be a mistake, which a 
> developer would want to work around by using LIMIT or something of the 
> sort in the query, but you're possibly still stuck killing your browser 
> to get out from underwater.

Indeed. The new model gets around this by doing all the heavy lifting in 
the background and only invoking the callback once we have data ready.


> If the callback received a result object which could be iterated over, 
> and had isValidRow() and isRowAvailable() both, then it could buffer 
> things AND break things into blocks, but that's probably annoying to 
> spec and code to.

Yeah, I think in v1 if browsers want to safeguard against multi-gigabyte 
results sets they should just raise implementation-dependent exceptions 
like "out of memory".


> It may be worthwhile to have explicit support for an error on the order 
> of "result set too large", without defining what "too large" might mean.  
> That could be a per-user-agent preference (or constant), and the error 
> mainly exists so that you can tell that you have a problem and provide a 
> lightweight code path if you want to support that user-agent.  
> Regardless, if gives the implementation the latitude to say "This far, 
> and no farther".

Certainly that would be reasonable. I have added it. People should let me 
know if they want me to remove or add error codes, by the way.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Friday, 12 October 2007 11:46:52 UTC