[Dbix-class] Class::DBI => DBIx::Class.

[Matt S Trout]

On Sat, Jan 21, 2006 at 08:11:19AM -0800, Alan Humphrey wrote:
> I can comment on this from my on-going porting experience which has
> generally been smooth.

It gets dog-fooded regularly; we still have a fair bit of CDBI code deployed
in various places ourselves, sadly.

> > I tried going the Loader route for my Schema based app.  No joy.  I've had
> to define each of my table classes by hand.  Not a huge deal, but having
> loader deal with the simple tables is something I miss.  If you don't need
> the Schema functionality this may not be an issue for you.

There's going to be a new DBIx::Class::Schema::Loader that addresses this
available around the same time as 0.05.

As of 0.05 you're always using a Schema anyway; just if you go the DB route
(which I strongly recommend against unless you're porting CDBI code) the
schema object is stashed as classdata on your DB class instead :)
 
> > Setting up relationships between tables takes some getting used to.  This
> is partly a problem with the docs (better, real world, examples would help)
> and partly a terminology issue.  For example, I was comfortable with the
> 'has_a' term.  "This bird has a genus" worked for me.  The new term is
> "belongs_to".  For whatever reason I didn't get comfortable with belongs_to
> until I started thinking "The genus_id column belongs to the genera table."

I nicked it from ActiveRecord; I've never been amazingly happy with has_a,
especially that it's overloaded to represent both FKs and column inflation.

> > Key differences for my app code:  the 'retrieve' method is now 'find' and
> 'get' is 'get_column'.

Sort of. If the column's inflated, that'll give you the deflated value, which
might catch you. Best bet is usually to replace $obj->get($name) with
$obj->$name.
 
> If you have a lot of set_sql statements, there is a bit more work but 
> afaik there hasn't been an SQL yet that couldn't be done in DBIC.
> 
> > This works two ways.  On the one hand the statement is true - you can get
> your SQL statements translated to DBIC.  On the other hand, I find the
> SQL::Abstract way of forming queries far from intuitive.  Complex queries,
> especially multi-table, are a struggle.

> Triggers are not supported, as it is currently felt that they are not 
> necessary.
> 
> > Hasn't been an issue for me.

And there's a cookbook entry showing how to do stuff without them; given the
C3 MRO if you need to run stuff before method 'foo' happens, just doing

sub foo { my $self = shift; $self->stuff_before_foo(@_); $self->next::method; }

does the trick fine without slowing everything else down while it checks to
see if there are triggers registered for everything else.
 
> Discussion, feature requests, bugs, problems, etc please visit 
> #dbix-class at irc.perl.org.
> 
> > The folks on this list (especially Mr. Trout) are fantastic.  Very
> helpful, very nice.  A great resource.

And better still, it makes me feel less guilty about what an appalling
documenter I am :)

-- 
     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/ +