[whatwg] Couple comments on Database storage spec.

[Scott Hess]

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