- From: Scott Hess <shess@google.com>
- Date: Fri, 5 Oct 2007 17:02:59 -0700
It may be worthwhile for Database to export a quote(arg) function, which will quote the argument in the appropriate manner for use in constructing a statement. This is useful for cases where it is challenging to reduce something to a static SQL statement with bind parameters. [A common case for this is something like "SELECT rowid FROM t WHERE c IN (...)", and you want to replace ... with an appropriately quoted comma-separated array.] I didn't fully understand how things would be ordered if there were multiple executeSql() trees open on a given Database object. For instance: executeSql('sql1', function (args) { executeSql('sql2', function (args) { executeSql('sql3', function (args) { }); }); executeSql('sql4', function (args) { }); }); executeSql('sql5', function (args) { }); I _think_ the spec implies 1, 5, 2, 4, 3 is the order (breadth-first). In section 4.11.4, would it be worthwhile to indicate that an empty result set would have rows which was exactly an empty array? Currently, it indicates that in case of failure rows must return null, but I could see an implementor returning null for an empty result set, also. [Maybe I'm reading too much in, here.] Should rowsAffected be expected to return 0 in case of a SELECT statement, or should it return the length of rows array? --- As a general comment, we've had some arguments within Gears about whether we should use the same function for both update queries and data-returning queries. Right now, everything goes through execute(), and if the query returned no data (such as "INSERT ..."), you get a ResultSet which doesn't need to be closed and where many functions throw exceptions. Likewise, if you call "SELECT ...", then sections of the results which make sense for updates (insertId, rowsAffected) make no sense. One suggestion within Gears was to have two functions: ResultSet query(sql, [arg, ...]); int do(sql, [arg, ...]); The first would return a ResultSet which needed to be closed, the second would return the number of rows changed by the query. The main thing is that what you do with your results would always depend on the API function you called, rather than the SQL statement you passed. You could still do query("INSERT...") or do("SELECT..."), but the return values would still be a ResultSet you needed to close, and 0, respectively. The Database storage spec does away with the Gears ResultSet.close() issue, but I think the idea still has merit. It could potentially do away with the ResultSet entirely, the different types of SQL query could have callbacks accepting the right few arguments directly. -scott
Received on Friday, 5 October 2007 17:02:59 UTC