On Oct 16, 2007, at 11:18 PM, Ian Hickson wrote:
Yes, that's possible. Let me know if the spec is still unclear on
this; I
tried to clarify it. (I'll be adding examples in due course, by the
way.)
I've seen about 10 different interpretations of the implicit
transaction and the effect of
On Oct 16, 2007, at 11:18 PM, Ian Hickson wrote:
On Fri, 5 Oct 2007, Scott Hess wrote:
In general, I am of the opinion that you should either have no
transactions, or explicit transactions, but never implicit
transactions.
This is a little different from a case like mysql, where you might
On Fri, 5 Oct 2007, Brady Eidson wrote:
I think `bool changeVersion()` has a deficient design, and the content
of its description - combined with the lack of clarity around active
and open transactions - makes implementing it even more dubious.
First off, it is synchronous.
Fixed.
But
On Oct 17, 2007, at 12:47 AM, Ian Hickson wrote:
But I also have some confusion about the actual intention of the
method.
The line that is the source of most confusion - When the method is
invoked, the user agent must obtain a full lock of the database
(waiting
for all open transactions
I think the conversation in this thread has gotten a little muddled.
The two main issues I see being discussed are:
1. Should single SQL statements be wrapped in a transaction?
2. Should the SQL API support explicit transactions (and therefore a
way to not fall into implicit transactions)?
On Oct 17, 2007, at 9:14 AM, Brady Eidson wrote:
On Oct 17, 2007, at 1:41 AM, Maciej Stachowiak wrote:
On Oct 17, 2007, at 12:33 AM, Brady Eidson wrote:
An admirable goal - one that I agree with. Which is why I think
the wisdom of the implicit transaction is dubious. Developers
that
On Oct 17, 2007, at 11:40 AM, Adam Roben wrote:
I think the conversation in this thread has gotten a little muddled.
The two main issues I see being discussed are:
1. Should single SQL statements be wrapped in a transaction?
2. Should the SQL API support explicit transactions (and therefore
On Oct 17, 2007, at 11:49 AM, Maciej Stachowiak wrote:
Downsides to this approach:
- You could only have one transaction in flight at once, so you'd
have to do scheduling in the app code if a transaction-starting UI
operation happens while you already have a transaction in
progress.
Aside: the net gain from shortening INVALID_STATE_ERROR to INVALID_STATE_ERR
is 2/19; is it worth sacrificing readability for 11% length?
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Brady Eidson
Sent: Wednesday, October 17, 2007 12:08 AM
To: Geoffrey
On 10/17/07, Maciej Stachowiak [EMAIL PROTECTED] wrote:
I'm not sure what other reasons Scott sees for (2). I do think it
would aid authoring clarity to have the word transaction in the API,
even if the model of how they are managed is much the same as
currently (so you can't forget to close
On Oct 17, 2007, at 1:14 PM, Scott Hess wrote:
On 10/17/07, Maciej Stachowiak [EMAIL PROTECTED] wrote:
I'm not sure what other reasons Scott sees for (2). I do think it
would aid authoring clarity to have the word transaction in the
API,
even if the model of how they are managed is much
On Wed, 17 Oct 2007, Křištof Želechovski wrote:
Aside: the net gain from shortening INVALID_STATE_ERROR to
INVALID_STATE_ERR is 2/19; is it worth sacrificing readability for 11%
length?
The exception names are decided by the W3C's DOM working group(s), I
recommend raising the issue with
On Oct 17, 2007, at 2:04 PM, Maciej Stachowiak wrote:
On Oct 17, 2007, at 1:14 PM, Scott Hess wrote:
On 10/17/07, Maciej Stachowiak [EMAIL PROTECTED] wrote:
I'm not sure what other reasons Scott sees for (2). I do think it
would aid authoring clarity to have the word transaction in the
On 10/17/07, Maciej Stachowiak [EMAIL PROTECTED] wrote:
On Oct 17, 2007, at 1:14 PM, Scott Hess wrote:
I think my concern is in two related bits:
A) As things currently stand, the developer simply can't roll their
own transaction structure. Passing BEGIN, COMMIT, or ROLLBACK to
On Oct 17, 2007, at 1:14 PM, Scott Hess wrote:
On 10/17/07, Maciej Stachowiak [EMAIL PROTECTED] wrote:
I'm not sure what other reasons Scott sees for (2). I do think it
would aid authoring clarity to have the word transaction in the
API,
even if the model of how they are managed is much
On 10/17/07, Scott Hess [EMAIL PROTECTED] wrote:
A) As things currently stand, the developer simply can't roll their
own transaction structure. Passing BEGIN, COMMIT, or ROLLBACK to
executeSql() doesn't do anything sensible. It's possible you could
somehow do something using temporary
On Wed, 17 Oct 2007, Scott Hess wrote:
Honestly, something like quote() is not necessary. It's just that
constructing SQL statements via concatenation is a hole I often see
people falling into. Having quote() allows you to construct safer SQL
statements, but people who construct
On 10/17/07, Brady Eidson [EMAIL PROTECTED] wrote:
Additionally, if we replaced closeTransaction() with
commitTransaction() and rollbackTransaction(), that would fit in with
my idea of disallowing BEGIN/COMMIT/ROLLBACK in executeSql() as the
developer would still have manual control over the
On 10/17/07, Aaron Boodman [EMAIL PROTECTED] wrote:
This is the first thing that makes me question the current implicit
transaction API :-(. Maybe adding a executeSqlInTransaction() would be
smarter. You can then separate the two meanings of SQLCallback:
- getting results of a sql call
-
On 10/18/07, Ian Hickson [EMAIL PROTECTED] wrote:
What would be cool is if we could detect, through tainting, the bad
codepaths. But I see no way to do that here.
could you simply require that all sql statements be of the form:
X = ? instead of X = 1
i.e., any attempt to not use parameterized
On Thu, 18 Oct 2007, timeless wrote:
could you simply require that all sql statements be of the form:
X = ? instead of X = 1
i.e., any attempt to not use parameterized expressions throws?
I know it's possible to screw this up, but would it at least be hard
enough?
Given that ? can
On Fri, 12 Oct 2007, Anne van Kesteren wrote:
I think there should be an error code for the database being full. For
some platforms there's not much storage space available and knowing
whether or not there's some space left is useful. So you can decide to
only store the critical data for
On Mon, 15 Oct 2007, Brady Eidson wrote:
In some embedded (and client-server) database implementations -
including SQLite - continuing to operate on a database that is known to
be corrupt can lead to the process crashing. Unlike the CPU core just
overheated case, it is a dangerous state
I don't feel quite passionately enough about this issue to pursue it
with much more vigor, but will make one remaining point:
On Oct 17, 2007, at 6:58 PM, Ian Hickson wrote:
On Mon, 15 Oct 2007, Brady Eidson wrote:
In some embedded (and client-server) database implementations -
including
Ian Hickson wrote:
On Wed, 17 Oct 2007, Scott Hess wrote:
Honestly, something like quote() is not necessary. It's just that
constructing SQL statements via concatenation is a hole I often see
people falling into. Having quote() allows you to construct safer SQL
statements, but people who
25 matches
Mail list logo
