[Catalyst] strange namespace behavior for dbic : schema

J. Shirley jshirley at gmail.com
Fri Jun 8 19:52:19 GMT 2007

On 6/8/07, Guy Debord <situationist at gmail.com> wrote:
> So is this not a good option if I want specific logic in Model::Foo but
> not Model::Bar ( I can't even create these without breaking )
> This seems to run contrary to my reading of the documentation and
> tutorials, etc.

Hi Guy,

I think that a diagram of how things are encapsulated would probably be of
assistance.  Sorry if I'm covering stuff you already know, just want to make
sure everything is thoroughly laid out.

First, it's important to know how things work outside of Catalyst.  The DBIC
classes you have can be used just like $schema->resultset('TableName'),
where $schema is (as I can see) a "TMP::Schema" object.

The DBIC::Schema helpers basically create a short-hand for you to access
"TableName", but they make you use some prefix.  This is really useful if
you have a model in your app called "User" but you also have a schema class
(a database table) named "User"

As an example, something like this:
   $c->model("User");        # Just some other model class
   $c->model("DB::User");  # A DBIC class resultset, equivalent to doing

So, just think that when you are doing "$c->model("DB::SomeTable")" you're
doing the equivalent of $schema->resultset("SomeTable");  And, as such,
$c->model("DB") would be somewhat analogous to returning the $schema object
-- except it doesn't, because that gets shoved off behind the scenes, and
Model::DBIC::Schema  creates a map between the ->resultset("TableName") and
model("DB::TableName") automatically, so you shouldn't need the $schema
object to get at the result sets.

The prefix there ("DB::") is configurable via the helper scripts, but is
very important (both for the reason I listed above w/ having other model
classes) and the way that Catalyst::Model::DBIC imports your schema classes
into your Catalyst application.

The syntax that Matt posted:
script/tmp_create.pl model DB DBIC::Schema TMP::Schema

Breaks down like this:
You're creating (tmp_create.pl) a model, with a prefix of "DB" that inherits
from "DBIC::Schema" and will use Helper::DBIC::Schema to generate the code.

The arguments beyond there ("TMP::Schema") are instructive to
Helper::DBIC::Schema to know what to map against.

Helper::DBIC::Schema then creates a map of the prefix ("DB") to

You're on the right track though, and what you said in the original post
about it getting "ugly" as the app grows I suppose is just a matter of
perspective.  You can always run without debugging enabled so you don't see
how things get dumped out.  But, it's all just information for you to look
at. Even without the ("DB::") prefix (or "Foo::" as you have in your
example) you'd still have to load each and every schema class into Catalyst
so that ->model(...) knows what to work with.

Hope this helps clear things up,

-- =

J. Shirley :: jshirley at gmail.com :: Killing two stones with one bird...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20070608/f00dd=

More information about the Catalyst mailing list