- From: Ian Hickson <ian@hixie.ch>
- Date: Fri, 12 Oct 2007 18:46:52 +0000 (UTC)
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