[whatwg] executeSql API is synchronous
Ian Hickson
ian at hixie.ch
Fri Oct 12 11:46:52 PDT 2007
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. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg
mailing list