My impatience got the better of me, so I had a shot with porting the
cdbi code to DBIx::Class::CDBICompat. I'm reliably informed that
once DBIx::Class 0.0810 is released in a few weeks, moving from CDBI
to DBIC::CDBICompat will be a simple matter of swapping out the use
base 'Class::DBI' to use base 'DBIx::Class::CDBICompat';
Then you get the DBIC feature set on top of your cdbi classes. I'm
reliably informed (via irc) that Bibliotech::DBI is too highly
customised for a straight port to dbic. However you still get the
DBIC_TRACE=1 sql diagnostics (including for inserts), and the more
transparent and swappable caching possibilities for very little effort.
So I tried:
$ mkdir connotea-dbic
$ cd connotea-dbic
$ mkdir lib
$ mkdir t
$ cp -R /path/to/connotea-code/bibliotech/Bibliotech/DBI* lib/
chuck a nice little test file in t/01-load-all.t (thanks to matt
trout :-) ):
use strict;
use warnings;
use Test::More ();
Test::More::plan('no_plan');
use Module::Pluggable::Object;
my $finder = Module::Pluggable::Object->new(
search_path => [ 'Bibliotech' ],
);
foreach my $class (sort $finder->plugins) {
Test::More::use_ok($class);
}
edit up the bibliotech config so the dsn is correct and go:
prove -l t
boom. the model is too tightly coupled to the controller and view.
so this is an example of a problematic line:
my $time = $Bibliotech::Apache::QUICK{DB} ||
$Bibliotech::Apache::MEMCACHE->get('DB');
I don't quite understand why I'm seeing dependencies to
Bibliotech::Component in the test ouptut too, but that's another
(probably more minor) problem.
I think all caching needs to be removed first then reintroduced
transparently. Given that refactoring to DBIC::CDBICompat is almost
certain to be easier and more productive in the long
run that doing a pure cdbi refactor, and that DBIC::Cursor::Cache
will work with the CDBICompat code (in the remote chance it doesn't
the community will certainly be responsive to failing test case and/
or patches). There's the path of least resistance to fixing this
problem. Also a good time to start writing tests for the model - I
can see why there aren't tests at the moment with the tight coupling.
Once that's done, it becomes straightforward to port some of the
larger methods to DBIC without the compat layer, and you start to
gain the huge benifits of easily interrogated classes and chainable
resultsets.
Going down this track is going to increase the chances of finding
committed volunteers (volunteers of some sort or another are the
lifeblood of open source software). The less cognitive overhead your
developers have while dealing with the software, the more likely
they'll stick with it, and the more likely you are to get quality code.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Connotea-code-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/connotea-code-devel
