[Catalyst] DBIC vs CDBI

[Matt S Trout]

On Wed, Feb 08, 2006 at 09:25:38AM -0500, catalyst at isidore.net wrote:
> So somewhere in the past few weeks while debugging a CDBI problem I vaguely remember seeing it mentioned that CDBI was obsolete in favor of DBIC. However, the CDBI wiki doesn't say anything of the sort, nor the CDBI perldocs. My first few attempts at trying to use DBIC have been less than satisfactory. Generated classes don't automatically setup relationships, there's no obvious ->retrieve function, and it just seems less friendly overall. So what's the official call about CDBI vs DBIC? Is CDBI really obsolete, and is DBIC really as hard to get working for a beginner as it appears coming from CDBI (Compat aside)? 
> 
> I'm trying to convince a buddy of mine that DBIC is the way to go, but I think I need convincing first :-)

DBIC came about because I got sick of fighting Class::DBI to write the
join code in Class::DBI::Sweet, and got sick of debugging silly CDBI edge
case bugs when I should have been billing clients.

It was originally envisaged as a better, more extensible Class::DBI - now
it's moving towards being that and using a far more powerful paradigm
(oriented around having separate objects for table, resultset, row rather
than table-as-class, row-as-object).

So for our development, Class::DBI has been deprecated in favour of
DBIx::Class - and more and more other people seem to be finding the same
thing. The docs still need work, but they're improving at high speed thanks
to a number of wonderful documentation contributors, and the mailing list
and IRC channel between them seem to manage to solve most people's problems.

Class::DBI is still quick to get started with, fairly useful in simple
projects (esp. where performance isn't an issue) and relatively stable
(although recent releases haven't been nearly so stable, sadly) and has a
huge array of plugins, although some combinations of those clash badly. But
I still wouldn't recommend it myself for new development; like Maypole, it's
mostly automagic with little substance underneath and tends to become a
straightjacket as projects grow (or you end up writing huge numbers of
set_sql statements to get round its static SQL approach etc. etc.).

I spent a number of years as a very happy Class::DBI user. I still don't
hate it, but it's accumulated enough cruft over its life it's pretty much
impossible to refactor it without breaking things (Tony Bowden and I have
both tried, and both come to the same conclusion - hence my announce for
DBIx::Class being titled "Taking the easy way out") so forward movement
will inevitably be faster for DBIx::Class.

(all the above my probably biased opinion - take as you will :)

-- 
     Matt S Trout       Offering custom development, consultancy and support
  Technical Director    contracts for Catalyst, DBIx::Class and BAST. Contact
Shadowcat Systems Ltd.  mst (at) shadowcatsystems.co.uk for more information

 + Help us build a better perl ORM: http://dbix-class.shadowcatsystems.co.uk/ +