[Catalyst] Mason + DBI + Catalyst?

[Matt S Trout]

On Tue, May 26, 2009 at 01:37:40AM +0200, Daniel Carrera wrote:
> Do you write your queries using straight SQL? For my application, MySQL 
> is a bottleneck. So it is important to me that I have control over the 
> queries to try to make them efficient. I don't have any query that spans 
> 8 tables though. So if you are happy with DBIC, then it should be good 
> enough for me too. I'll take a second look at DBIC.

Have a look at -

http://www.shadowcat.co.uk/catalyst/-talks/yapc-na-2008/dbix-masterclass.xul

http://www.shadowcat.co.uk/archive/conference-video/yapc-eu-2008/dbic-masterclass/

http://xrl.us/oubg6 

Those should give you an idea of the level of complexity that can be built
up elegantly.
 
> Btw, why is it called DBIC if CPAN says DBIx::Class?

DBIx is the namespace for DBI extensions.

So we use DBIC as an abbreviation.

> >Being able to chain resultsets makes it much much easier than using 
> >straight SQL, and you write less code.  If you have a query you've 
> >constructed called $query, and lets say you now only want active records 
> >you can do $query = $query->search({ active => 1 });  In this way you 
> >can filter many things incrementally.
> 
> But is that efficient? It looks like you are getting MySQL to return the 
> entire data set and then making Perl filter it. That can't be efficient.

->search just constructs another resultset.

DBIC doesn't hit the database until you make it via ->count or ->next/->all
(or something that calls one of those).

That's rather the key advantage of DBIC - a resultset is basically a sort of
lazy virtual view onto your database that turns itself into an SQL query as
and when (and only when) required to do so by something you want.

-- 
        Matt S Trout         Catalyst and DBIx::Class consultancy with a clue
     Technical Director      and a commit bit: http://shadowcat.co.uk/catalyst/
 Shadowcat Systems Limited
  mst (@) shadowcat.co.uk        http://shadowcat.co.uk/blog/matt-s-trout/