[Catalyst] Model API compliance

Matt S Trout dbix-class at trout.me.uk
Mon Sep 4 20:26:15 CEST 2006

Mark Blythe wrote:
> On 9/4/06, *Rodney Broom* <rbroom+catalyst at rbroom.com 
> <mailto:rbroom+catalyst at rbroom.com>> wrote:
>     I'm looking for a doc on what exactly a new model API should
>     implement to be compliant with Catalyst as we're considering rolling
>     our own for performance and other features. Currently we can use
>     CDBI and DBIx, but we wouldn't want to re-implement every aspect of
>     these APIs in order to work under Catalyst.
>     My guess is that no such document yet exists, and that it would be a
>     back-compat nightmare to state a limited set of what CDBI/DBIx
>     features things like plugins are allowed to use.
> I don't believe Catalyst makes any assumptions about what a given model 
> can do.  As far as I can tell, the only thing it expects is that a model 
> should be a sub-class of Catalyst::Model.

Even that's not a requirement. The only requirement is "is a perl class".

If you want to be instantiated as a per-app object ("instance" component type 
rather than "class" in the initial debug stuff) you need to provide a 
COMPONENT method (which you can get by subclassing Catalyst::Model but can 
happily implement yourself if you prefer, too).

I'd be interested to hear your "performance and other reasons" on the DBIC 
list though, I've never yet encountered a situation where dropping DBIC 
entirely was required to solve performance issues.

      Matt S Trout       Offering custom development, consultancy and support
   Technical Director    contracts for Catalyst, DBIx::Class and BAST. Contact
Shadowcat Systems Ltd.  mst (at) shadowcatsystems.co.uk for more information

+ Help us build a better perl ORM: http://dbix-class.shadowcatsystems.co.uk/ +

More information about the Catalyst mailing list