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

[Todd Lorenz]

Thanks much, everyone, for you kind feedback. Very helpful, and heartening.

TRL


>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/ +
>
>_______________________________________________
>List: http://lists.rawmode.org/cgi-bin/mailman/listinfo/dbix-class
>Wiki: http://dbix-class.shadowcatsystems.co.uk/
>IRC: irc.perl.org#dbix-class
>SVN: http://dev.catalyst.perl.org/repos/bast/trunk/DBIx-Class/