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

[Will Hawes]

Alan Humphrey wrote:
> I can comment on this from my on-going porting experience which has
> generally been smooth.

Thanks for the feedback :)

> 
> -----
> 
> You get better performance, plus improved functionality including built 
> in paging, multi-column primary keys and grouping.
> 
>> I found the built in paging to be very helpful.  If you've used Sweet it's
> painless.
> 
> Porting code from CDBI is very straightforward for simple cases - all it 
> really involves is changing some syntax for your model classes and 
> possibly a few lines of template code. If your model classes are 
> generated by Loader, there may be even less to do ;)
> 
>> 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.

DBIC::Loader is under development so this may have already been 
addressed or in the pipeline.

> 
>> 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."

Good point, although the syntax is very similar and with the exception 
of has_a being renamed belongs_to, there aren't any major differences.

>> You may not have the same problem, but be aware that there are some
> differences in terminology and you'll have to learn them.  The docs, while
> thin in places, are generally good.  They'll get you most of the way
> through.

Docs are being actively improved, don't check resultset branch in SVN 
regularly :)

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

Noted, will get these included in the docs.

> 
> 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.

SQL::Astract takes some learning but once you have the basics it is 
pretty simple to use. I'm plagiarizing the list archive and hope to have 
more examples of complex queries documented soon. If there are any you 
are struggling with, please forward to the list for dissemenation :)

> Triggers are not supported, as it is currently felt that they are not 
> necessary.
> 
>> Hasn't been an issue for me.
> 
> 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.

Agreed. But then again, he is the author :)