#dbixconnector
- DBIx::Connector and Serializable Snapshot Isolation
https://justatheory.com/2011/09/dbix-connector-and-ssi
- Catalyst with DBIx::Connector and Template::Declare
https://justatheory.com/2009/11/catalyst-tutorial-continued
Following up on my post yesterday introducing Catalyst::View::TD, today I’d like to continue with the next step in chapter 3 of the Catalyst tutorial. The twist here is that I’m going to use PostgreSQL for the database back-end and start introducing some database best practices. I’m also going to make use of my DBIx::Connector module to interact with the database.
- DBIx::Connector Updated
https://justatheory.com/2009/10/dbix-connector-updated
- Database Handle and Transaction Management with DBIx::Connector
https://justatheory.com/2009/10/dbix-connector
As part of my ongoing effort to wrestle Catalyst into working the way that I think it should work, I’ve just uploaded DBIx::Connector to the CPAN. See, I was using Catalyst::Model::DBI, but it turned out that I wanted to use the database handle in places other than the Catalyst parts of my app. I was bitching about this to mst on #catalyst, and he said that Catalyst::Model::DBI was actually a fork of DBIx::Class’s handle caching, and quite out of date. I said, “But this already exists. It’s called connect_cached().” I believe his response was, “OH FUCK OFF!”
- Serious Exception-Handling Bug Fixed in DBIx::Connector 0.42
https://justatheory.com/2010/12/serious-dbix-connector-bug-fixed
- Suggest Method Names for DBIx::Connector
https://justatheory.com/2009/10/dbix-connector-methods
Thanks to feedback from Tim Bunce and Peter Rabbitson in a DBIx::Class bug report, I’ve been reworking DBIx::Connector’s block-handling methods. Tim’s objection is that the the feature of do() and txn_do() that executes the code reference a second time in the event of a connection failure can be dangerous. That is, it can lead to action-at-a-distance bugs that are hard to find and fix. Tim suggested renaming the methods do_with_retry() and txn_do_with_retry() in order to make explicit what’s going on, and to have non-retry versions of the methods.
- DBIx::Connector Exception Handling Design
https://justatheory.com/2011/05/dbix-connector-catch
In response to a bug report, I removed the documentation suggesting that one use the catch function exported by Try::Tiny to specify an exception-handling function to the DBIx::Connector execution methods. When I wrote those docs, Try::Tiny’s catch method just returned the subroutine. It was later changed to return an object, and that didn’t work very well. It seemed a much better idea not to depend on an external function that could change its behavior when there is no direct dependency on Try::Tiny in DBIx::Connector. I removed that documentation in 0.43. So instead of this: