Hi all,
even if wasn't here for a long time (Merijn finally kicked my ass on this
list), I uploaded the (from my point of view) latest development version of
1.21 for SQL::Statement.
I know there're some changes in it, which may break existing code - but I
don't know which code is existing world
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
Howdy Tim et al.,
I've just released [DBIx::Connector](http://search.cpan.org/perldoc?DBIx::Connector
) to the CPAN. It does connection caching and transaction management,
borrowing pages from `connect_cached()`, Apache::DBI, and DBIx::Class,
but usable in any of these environments. The
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
David E. Wheeler wrote:
I've just released
[DBIx::Connector](http://search.cpan.org/perldoc?DBIx::Connector) to the
CPAN. It does connection caching and transaction management, borrowing
pages from `connect_cached()`, Apache::DBI, and DBIx::Class, but usable
in any of these environments. The
On Oct 5, 2009, at 5:41 PM, Darren Duncan wrote:
But from what you've described in your blog to be the state of
affairs, I think that having a distinct DBIx::Connector module is a
good idea, versus embedding that functionality in a larger DBI-using
module.
Yes, that's the idea.
I've
