On 9/24/07, Ian Hickson [EMAIL PROTECTED] wrote:
On Thu, 20 Sep 2007, Anne van Kesteren wrote:
The SQL API doesn't seem to define how to deal with errors, such as:
snip
* Database that is full
This currently just reports an error with code 1, like everything else,
but in due course we
On 9/24/07, Ian Hickson [EMAIL PROTECTED] wrote:
On Sat, 22 Sep 2007, Timothy Hatcher wrote:
The callback syntax is nice but the implicit thread-global transaction
is confusing and can lead to programmer error and unneeded database
locking.
There isn't really a thread-global transaction,
On 9/24/07, Ian Hickson [EMAIL PROTECTED] wrote:
On Sun, 23 Sep 2007, David wrote:
What if I want to handle the RS by blocks of 100 rows ?
Why wouldn't you just want to do everything?
For the case of a database with a 5M size limit, never.
If app developers, users, and browsers all agree
Scott just pointed out to me that the current spec has executeSql
taking a variable number of arguments:
http://www.whatwg.org/specs/web-apps/current-work/#executesql
We tried this in Gears at first, but learned quickly that it was a
huge pain to work with. Dealing with the arguments collection
To clarify, my proposed alternative is that the second argument should
just be an array:
executeSql(sql, [foo, bar, baz], callback);
- a
On 10/5/07, Aaron Boodman [EMAIL PROTECTED] wrote:
Scott just pointed out to me that the current spec has executeSql
taking a variable number of arguments:
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
On 10/5/07, Scott Hess [EMAIL PROTECTED] wrote:
In the first case, since we're working within the browser, there's
generally really nothing to be done, so most stuff falls to the second
case. At that point, it would be useful to have a human-readable
error string generated by the library
Also, in case of no bind arguments, Gears allows the parameter to be
either empty or null or omitted (that not being an option in this
case).
-scott
On 10/5/07, Aaron Boodman [EMAIL PROTECTED] wrote:
To clarify, my proposed alternative is that the second argument should
just be an array:
Besides some cleanup and clarification on wording that has been
discussed on this list, I think the spec is pretty solid - except for
one blocker.
I think `bool changeVersion()` has a deficient design, and the content
of its description - combined with the lack of clarity around active
Summary: variable length arguments seem cute at first, but end up
being more pain that they are worth.
Indeed!
Another reason we moved away from varargs in Gears was because it made
some APIs impossible to extend later. For example, this:
method(v1_string_arg, v1_array_arg,
10 matches
Mail list logo
