- From: Brady Eidson <beidson@apple.com>
- Date: Wed, 12 Dec 2007 12:12:07 -0800
On Dec 12, 2007, at 11:18 AM, Dimitri Glazkov wrote:
> Can you help me understand the problem you're pointing out? The
> difference between the idea outlined and the current spec is the
> absence of the transaction callback, but it basically (I think) has
> the equivalent net effect.
In the current spec, you know exactly when your transaction is "in
flight" and available, because of the callback. That's why
executeSql() is only allowed from within a transaction or statement
callback.
An app might decide to do something differently if the transaction
callback doesn't come within a certain timeout, for example.
Additionally, the current spec reflects the reality that a transaction
might not be allowed - getting the SQLTransactionErrorCallback right
away.
Additionally, it is a common pattern to execute different sql
statements based on the outcome of the previous statement or based on
other program state when the time comes to decide what statement to
execute next.
Your proposed model hides these realities to various degrees. By
allowing a queue of statements to build up then "pulling the trigger",
there's no definitive point in time where the transaction actually
begins executing, and a lot of work might be wasted queueing up a long
list of statements before pulling that trigger, and other flexibility
might be lost.
> db.createTransaction is just a mutable list of statements until the
> execute method is called. In fact, it could even probably be just a JS
> array.
Making it an array seems flawed - separate method calls is the right
way to go, I think.
> tx.execute(..) immediately returns, then asynchronously (pardon the
> sketchiness):
> * opens transaction
> * calls optional errorCallback if fails
> * proceeds to execute statements in queue
> * calls optional successCallback upon success.
The current spec prevents you from queueing up statements until the
transaction is guaranteed to be open already. Speaking with direct
implementation experience, I can attest that this is a Good Thing
(tm). See some of the reasons above.
> I don't see it as being too much different from the spec's transaction
> steps. In fact, I can easily see this written as a JS wrapper around
> the current spec.
If you think your model is easier, then I agree completely that it can
be implemented as a JS wrapper around the current API. But it hides
details and options available in the current API as previously
discussed. It would be good for some developers (I'm assuming you ;)
but not for others.
One thing your model would do over the current spec is make the API
more complex. I see more fuzzy interactions between the objects and
more methods that don't make as much sense to me as the current spec.
For example...
>>>> .. in which case single statements could be executed as:
>>>>
>>>> db.sql('select count(*) as count from chickadees', [],
>>>> function(rs) {
>>>> console.log(rs.rows.count); }).execute();
Huh? While I think the ability to simply execute a single statement
without worrying about callbacks and transactions is valuable, the
above syntax combined with the previously described relationship
between db.sql() and tx.execute() makes my brain explode. :)
I don't disagree that a simple way to execute a single statement is
valuable, but I was thinking something more along the lines of using
the current model as-is, and adding a method to database that has the
first statement queued up in a transaction already.
~Brady
Received on Wednesday, 12 December 2007 12:12:07 UTC