doesn't have one either for savepoints.
It uses COMMIT for that.
--
Jonathan Leffler jonathan.leff...@gmail.com #include disclaimer.h
Guardian of DBD::Informix - v2008.0513 - http://dbi.perl.org
Blessed are we who can laugh at ourselves, for we shall never cease to be
amused.
Okay. I'm open to savepoint methods being added.
We'll go with savepoint($name), release_savepoint($name) and
rollback_to_savepoint($name) as method names.
Got a commit bit?
Tim.
On Oct 7, 2009, at 3:24 PM, Tim Bunce wrote:
We'll go with savepoint($name), release_savepoint($name) and
rollback_to_savepoint($name) as method names.
Got a commit bit?
No.
David
On Tue, Sep 29, 2009 at 02:56:41PM -0700, David E. Wheeler wrote:
On Sep 29, 2009, at 2:51 PM, Darren Duncan wrote:
Going the other way, in SQL, there is a single terse SQL statement for
starting/ending transactions, and doing the thing with savepoints. So for
aside from maybe some
On Oct 5, 2009, at 5:01 AM, Tim Bunce wrote:
We already have the example of DBI transaction support; savepoints
are just
an extension of that.
Well, as you said earlier David, Transactions Savepoints.
No, but they're closely related.
Commit and rollback are methods partly to support
David E. Wheeler wrote:
On Oct 5, 2009, at 5:01 AM, Tim Bunce wrote:
I'd be interested if someone could do the research to list what
databases support savepoints and what syntax they use for the main
statements.
DBIx::Class has done this for a lot of databases. Check out
MSSQL:
SAVE
On Oct 5, 2009, at 12:23 PM, Darren Duncan wrote:
SQLite also has savepoints, since 3.6.8 around January.
See http://sqlite.org/lang_savepoint.html for details.
SQLite:
SAVEPOINT $name
RELEASE [SAVEPOINT] $name
ROLLBACK [TRANSACTION] TO [SAVEPOINT] $name
Adding that to DBIx::Class
Tim et al.,
Anyone given any thought to an interface for savepoints? They're a
part of the SQL standard, and basically look like named
subtransactions. The SQL looks like this:
BEGIN;
INSERT INTO table1 VALUES (1);
SAVEPOINT my_savepoint;
INSERT INTO table1
I think I've talked about this before. I see that the best generic interface
for savepoints is to make them look like normal sub-transactions, that are scoped:
1. The basic idea is that we have nested transactions, and starting a child is
defining a subunit that needs to succeed
On Sep 29, 2009, at 12:34 PM, David E. Wheeler wrote:
Compared to transactions, the statements look like this:
TRANSACTIONS | SAVEPOINTS
-
BEGIN;| SAVEPOINT :name;
COMMIT; | RELEASE :name;
ROLLBACK; | ROLLBACK TO :name;
Apologies, I
nested transaction of its own.
There should not be an autocommit=0 in the interest of consistency.
Are you saying that a transaction not be required for savepoints? I'm
pretty sure that a transaction is required for savepoints. Perhaps a
call to savepoint() implicitly starts a transaction
Going the other way, in SQL, there is a single terse SQL statement for
starting/ending transactions, and doing the thing with savepoints. So for aside
from maybe some consistency with legacy DBI features, why should DBI objects
have begin/commit/rollback or methods specific to start/end
On Sep 29, 2009, at 2:51 PM, Darren Duncan wrote:
Going the other way, in SQL, there is a single terse SQL statement
for starting/ending transactions, and doing the thing with
savepoints. So for aside from maybe some consistency with legacy
DBI features, why should DBI objects have begin
) any changes made since the named savepoint, if the database
supports savepoints and CAutoCommit is off.
=item Csavepoint_remove
$rc = $dbh-savepoint_remove($savepoint_name) or die $dbh-errstr;
Removes the named savepoints, if the database supports savepoints and
CAutoCommit is off
14 matches
Mail list logo
