[Catalyst] catalyst tutorial: MyAppDB/Book.pm vs. MyApp/Model/Book.pm

[Matt S Trout]

On Tue, May 15, 2007 at 03:47:57AM -0700, mla wrote:
> I find the Rails ActiveRecord interface pretty appealing:
> 
>   http://ar.rubyonrails.com/classes/ActiveRecord/Base.html

DBIC's interface is not dissimilar although it favours data structures
for query descriptions rather than raw SQL.
 
> I like the notion of protected fields (attr_protected and
> attr_accessible) to allow mass assignment directly from the
> request parameters.

This is perl.

my @ok = qw(foo bar baz quux);

my %set; @set{@ok} = @{$c->req->params}{@ok};

$dbic_obj->update(\%set); # but gods please validate first for production

> I like how if you fetch columns that don't exist in the table
> the object becomes read-only by default.

That's neat, although I prefer tools that presume I know that I'm doing.

> And the find() interface seems nice, where basically the
> select is just broken into its components (e.g., condition,
> order, group, limit, offset). I know they add a bunch of
> helper fetch methods through their autoload mechanism.

Yeah, I find this kinda funny. Rails guys go "look, LOOK" about the equiv. of

find_by_login($login)

DBIC just handles

find({login => $login})

which saves autoload madness at the cost of ... TWO CHARACTERS ...

> So with that design you'd get the centralized validation, which
> is most critical to me, but then you could use SQL freely
> and get back a collection of read-only active record objects
> if you did fancy stuff.

You -can- pass a custom chunk of SQL to DBIC for the where clause and have
it Just Handle It. The fact that most people choose not to is, however, a
hint as to where the better engineering practice lies :)

> I'll read through DBIx::Class some more. The thing where the
> models are used through the schema seemed weird to me and I don't
> fully understand it yet. I'd really like to be able to "use Try::User"
> and be able to create and update it rather than going through an
> explicit db schema layer. I guess I could create another object
> that wraps around the DBIx::Class module or something.

Under Cat you'd just be doing $c->model('DB::User') and everything would work.

The reason for the explicit schema object is to handle multiple connections
elegantly (see recent blog madness for the nasty hacks used to make AR sort
of handle it if you change all your code to use a different syntax).

If you're sure you only need one connection, DBIC -will- let you set the
connection at the class level. It's just kinda gross so people generally don't.

-- 
      Matt S Trout       Need help with your Catalyst or DBIx::Class project?
   Technical Director    Want a managed development or deployment platform?
 Shadowcat Systems Ltd.  Contact mst (at) shadowcatsystems.co.uk for a quote
http://chainsawblues.vox.com/             http://www.shadowcatsystems.co.uk/