--- [EMAIL PROTECTED] wrote:
> Joe Wilson <[EMAIL PROTECTED]> wrote:
> > --- [EMAIL PROTECTED] wrote:
> > > It may be more difficult to implement this in a backwards-compatible
> > > way such that older versions of SQLite can rollback a journal created
> > > by a newer version if it encounters
It seems to me that the biggest worry about nested transactions is backwards
compatibility. So, first, let me reiterate some points:
1). Actual changes to the database occur thru only one user at a time and
modify the database directly.
2). The journal is created by this one user and is a record
Darren Duncan wrote:
I wasn't speaking in absolutes there, only in the context that if
child transactions were implemented, and there were 2 ways to do it,
then which way might have the least impact would be the way that most
closely resembles SQLite's current behaviour.
Yes, I know. I
Joe Wilson <[EMAIL PROTECTED]> wrote:
> --- [EMAIL PROTECTED] wrote:
> > It may be more difficult to implement this in a backwards-compatible
> > way such that older versions of SQLite can rollback a journal created
> > by a newer version if it encounters one.
>
> I wonder if there are many
--- [EMAIL PROTECTED] wrote:
> It may be more difficult to implement this in a backwards-compatible
> way such that older versions of SQLite can rollback a journal created
> by a newer version if it encounters one.
I wonder if there are many projects that have different versions of
SQLite
At 6:45 PM -0700 4/10/07, Darren Duncan wrote:
If one wants to still deny that rolling back a child without rolling
back a parent has no practical use, then we might as well not have
built-in SQL statements that are atomic, because that is exactly the
same end result for users.
If someone is
At 6:05 PM -0600 4/10/07, Dennis Cote wrote:
Darren Duncan wrote:
I think that the question of what would be a reasonable minimum to
do now depends on what SQLite's current behaviour is when an
individual SQL statement fails that is part of a larger transaction.
Of course not. A reasonable
, April 10, 2007 5:45 PM
To: sqlite-users@sqlite.org
Subject: RE: [sqlite] SQLite and nested transactions
At 9:20 AM -0400 4/10/07, Samuel R. Neff wrote:
>Under what circumstances would an older version of SQLite be
>used to rollback a newer journal?
Situations I am thinking of include wanting
Darren Duncan wrote:
I think that the question of what would be a reasonable minimum to do
now depends on what SQLite's current behaviour is when an individual
SQL statement fails that is part of a larger transaction.
Of course not. A reasonable minimum is to do nothing and leave SQLite as
At 9:20 AM -0400 4/10/07, Samuel R. Neff wrote:
Under what circumstances would an older version of SQLite be
used to rollback a newer journal?
Situations I am thinking of include wanting to use multiple
application programs with the same database, and each one includes a
different version of
At 11:46 AM -0600 4/10/07, Dennis Cote wrote:
Samuel R. Neff wrote:
I personally would see value in supporting quasi-nested transactions where
they are nested in name only--increment decrement a counter and commit on
last commit, rollback entire transaction on first rollback. This would have
Samuel R. Neff wrote:
I personally would see value in supporting quasi-nested transactions where
they are nested in name only--increment decrement a counter and commit on
last commit, rollback entire transaction on first rollback. This would have
the advantage that the library would support
ington D.C. metro area. If interested
contact [EMAIL PROTECTED]
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Monday, April 09, 2007 9:52 PM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] SQLite and nested transactions
It may be more difficult to
I personally would see value in supporting quasi-nested transactions where
they are nested in name only--increment decrement a counter and commit on
last commit, rollback entire transaction on first rollback. This would have
the advantage that the library would support issuing multiple BEGIN
"Igor Tandetnik" <[EMAIL PROTECTED]> wrote:
>
> I'd still like some limited notion of a savepoint to be implemented, to
> support enlisting a SQLite node into a distributed transaction. You see,
> three-phase distributed commit protocol requires the possibility of a
> "roll-forward" state. In
PROTECTED] wrote:
I have just read the omitted features section and noticed that SQLite doesn't
support nested transactions.
What effort is required to add this feature?
What would be the next best DB that does support this feature?
Ray
PROTECTED]
Gesendet: Montag, 9. April 2007 19:50
An: sqlite-users@sqlite.org
Betreff: RE: [sqlite] SQLite and nested transactions
Regarding: "...As Igor pointed out this does not resemble a full
implementation of transactions, as nested transactions can be committed and
rolled back independ
Regarding: "...As Igor pointed out this does not resemble a full
implementation of transactions, as nested transactions can be committed
and rolled back independently of the outer parent transaction."
Nonetheless, it would seem, just from the couple of pages below, that
some DB vendors find the
:[EMAIL PROTECTED]
Gesendet: Montag, 9. April 2007 18:38
An: sqlite-users@sqlite.org
Cc: Dennis Cote
Betreff: Re: [sqlite] SQLite and nested transactions
So. If i read this code right.
* The transaction_level keeps track of how many nested transactions have
occurred.
* Only the parent transaction
So. If i read this code right.
* The transaction_level keeps track of how many nested transactions have
occurred.
* Only the parent transaction allows the commit.
In this case, only a single journal is required (the parent journal).
Thanks,
Ray
Dennis Cote <[EMAIL PROTECTED]> wrote:
>
Darren Duncan wrote:
I will clarify that child transactions are just an elegant way of
partitioning a larger task, and that parent transactions always
overrule children; even if a child transaction commits successfully, a
rollback of its parent means there are no lasting changes.
Darren,
Darren Duncan <[EMAIL PROTECTED]> wrote:
> At 4:38 PM -0700 4/5/07, Darren Duncan wrote:
> >To get this to work would basically involve having additional
> >journal files, with the original one being for the parent-most
> >transaction, and with an additional one for each transaction
At 4:38 PM -0700 4/5/07, Darren Duncan wrote:
To get this to work would basically involve having additional
journal files, with the original one being for the parent-most
transaction, and with an additional one for each transaction level,
or some such arrangement; the extra ones could have
At 3:43 PM -0700 4/5/07, <[EMAIL PROTECTED]> wrote:
I have just read the omitted features section and noticed that
SQLite doesn't support nested transactions.
Which is *very* unfortunate indeed. It would be *so* much easier for
users to get atomicity right at multiple levels if
I have just read the omitted features section and noticed that SQLite doesn't
support nested transactions.
What effort is required to add this feature?
What would be the next best DB that does support this feature?
Ray
25 matches
Mail list logo
