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 or be a
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
On Sep 29, 2009, at 2:25 PM, Darren Duncan wrote:
1. The basic idea is that we have nested transactions, and starting
a child is defining a subunit that needs to succeed or be a no-op as
a whole.
I agree in principal; DBIx::Class has this feature, and it's fairly
nice. I'm borrowing it
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
