[Dbix-class] Issues getting Catalyst::Model::DBIC::Schema to layer lib/MyApp/Model/Foo.pm on top of generated version

[Scotty Allen]

> It's just borked.  It was added in as a last minute thing in the hopes
> that a simple ->require was good enough to give at least some
> functionality to someone.  Clearly that's not the case.

Ah, ok:)  I wondered if maybe that was the case...

> But in any case, here's a few other things on this subject in general:
> 
> 1) If you're using DBIx::Class::Schema::Loader (or the Helper which in
> turn uses it, C::H::M::DBIC::SchemaLoader), you can layer effectively
> back at the Schema rather than the Model layer. 
> DBIx::Class::Schema::Loader's layering actually works, whereas the one
> at the Model level is obviously borked.  The reason we need to support
> it at both levels is that sometimes you want to override things in the
> Schema itself (for all code that uses your Schema), and sometimes you
> want to override stuff just in the Catalyst Model (to do
> Catalyst-specific things that perhaps other non-Catalyst Schema-using
> code might not want to see).  The different is entirely acedemic if
> the Schema is local to your Cat app only.

Ah, I was thinking about this earlier today, and wondering if it was
possible, and likely preferable (at least for the vast majority of what
I need to do).  Good to know this is possible.

> What the Model level really needs is all of the exact same layering
> support that the Schema level currently has, but it's slightly
> trickier to actually get that done at the Model end, more magic
> involved.  The %INC problem is because Catalyst itself already loaded
> your model class I believe, which I guess means it ignored the "die
> foo" (which sounds pretty normal).  Given that Catalyst will load your
> layered file at some point anyways, the ->require I stuffed in there
> was probably completely superfluous, and at the same time, still kinda
> broken :)

Yep, this makes sense to me. I hadn't fully thought through why they
were already loaded, but it makes sense, as AFIAK, Catalyst loads
everything in lib/MyApp/Model straight off the bat.  I'm not clear why
it didn't hit the die in my test code though...

> 2) Even after you hacked the ->require part to work (or if you using
> Schema rather than Model layering as above), a subroutine in the
> layered class definition will not show up as
> $c->model('Foo::Bar')->foo();.  $c->model('Foo::Bar') is a ResultSet,
> and subroutines placed in that file do not end up in the default
> ResultSet for your source, rather they end up in the source class
> definition.  This is a DBIx::Class::Schema thing in general, see the
> Schema/ResultSet/ResultSource/etc docs. 
> $c->model('Foo::Bar')->result_source->foo() may have worked.
> 
> You can get new functions into the ResultSet part, but it's a little
> trickier.  There's some support for doing it automagically via a
> component called DBIx::Class::ResultSetManager that lets you define
> "sub foo : ResultSet { }" in that same .pm file, and the sub will show
> up in the ResultSet.  However, I think this interface is brand new and
> possibly subject to change sometime soon.

Ah, ok, cool.  I'd seen ResultSetManager recently, and wondered what it
was for, but hadn't had a chance to look into it:)  I guess I'll start
playing with it, and run the risk of having the interface change on me.

I'm having a hard time figuring out why you _wouldn't_ want to add your
methods to the ResultSet, though.  Is this something akin to a class
method vs. object method separation?

Thanks for all the great info,

Scotty
--
scotty at scottyallen.com