DRH,
The thing that confuses me is the concept of "TRANSACTION stack" vs a
transaction. I believe what your trying to say is there is still only one
transaction but there are multiple savepoints that are implemented via a stack.
And the transaction is either commited or rolled back. Savepoints are either
marked (pushed onto the stack) or released (deleted from the stack). And
releasing the first savepoint is in effect a commit..
Maybe distinguishing between a transaction vs a savepoint as a mark or location
within the transaction would be helpful.
Also it might be simpler to understand that Transactions are committed.
Savepoints are released (deleted from the savepoint stack). And that
"rollbacks to" partially undo a transaction and revert the state of the DB to
just after the named savepoint.
This might change the implementation slightly but it would avoid the confusing
concept of "release" sometimes == commit... UGH...
Savepoint thus would not be allowed to "create a new transaction"
rollback without the TO would do the following:
reverts the state of the database file to prior to the begin.
Clears all savepoints
Rollback with the TO would do the following:
Perform a rollback of a the transaction to just after the savepoint name.
Removes savepoints after the named savepoint.
Leaves the savepoint name on the stack so it can be re-used again in a
subsequent rolllback/release.
Release: Either DO not implement or it could just do the following:
Removes the savepoint name from the savepoint stack. All subsequent and
prior names on the stack would remain intact.
Just my .02 on the meaning of savepoints and distinguishing between a savepoint
and a transaction.
Ken
--- On Fri, 1/2/09, D. Richard Hipp <d...@hwaci.com> wrote:
> From: D. Richard Hipp <d...@hwaci.com>
> Subject: Re: [sqlite] Transaction within script
> To: "General Discussion of SQLite Database" <sqlite-users@sqlite.org>
> Date: Friday, January 2, 2009, 10:29 AM
> On Jan 2, 2009, at 10:56 AM, Igor Tandetnik wrote:
>
> > "D. Richard Hipp" <d...@hwaci.com>
> wrote
> > in message
> news:ff9afacd-4cde-4d66-a15f-3b9226df0...@hwaci.com
> >> Preliminary documentation can be seen at
> >> http://www.sqlite.org/draft/lang_savepoint.html
> >
> > Describing the effects of RELEASE statement as
> committing a savepoint
> > may be somewhat misleading. How can one commit some
> changes in the
> > middle of a transaction? What happens to those
> committed changes if
> > the
> > entire transaction is rolled back later?
>
> I have attempted to clarify the documentation. Please let
> me know if
> it makes better sense now.
>
> http://www.sqlite.org/draft/lang_savepoint.html
>
>
> >
> >
> > At least I, personally, was thoroughly confused by it,
> and got
> > un-confused only after reading Postgress'
> documentation which
> > describes
> > the effects of RELEASE statement as "destroys a
> savepoint, makes it
> > unavalilable for rollback, but has no other user
> visible behavior".
> > Basically, as I understand it, RELEASE simply makes it
> as if the
> > SAVEPOINT statement it names (and all subsequent ones)
> never
> > happened -
> > except when the SAVEPOINT in question initiated the
> transaction in the
> > first place (which, as I understand, is illegal in
> Postgress), in
> > which
> > case RELEASE is the same as COMMIT.
> >
> > Igor Tandetnik
> >
> >
> >
> > _______________________________________________
> > sqlite-users mailing list
> > sqlite-users@sqlite.org
> >
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
> D. Richard Hipp
> d...@hwaci.com
>
>
>
> _______________________________________________
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
