[Dbix-class] "table" methods in schemas?

[Matt S Trout]

On Tue, Jan 31, 2006 at 03:58:11PM -0600, Brandon Black wrote:
> I know we covered this on irc at some point, but I'm still at a loss
> as to the "correct" way to do these types of things.
> 
> For example, in the old/bad way of doing things, a table-class
> MyDB::FooTable might have a method like:
> 
> sub get_event_data {
>     my $class = shift;
>     my $eventid = shift;
> 
>     my $data = [];
> 
>     my $rs = $class->search({ evid => $eventid });
>     while(my $row = $rs->next) {
>         # even dumber, update row data when viewed :)
>         $row->seen = $row->seen + 1;
>         $row->update();
>         push(@$data, { x => ($row->x || 22), ... });
>     }
> 
>     return $data;
> }
> 
> And in an application I might do:
> 
> MyDB::FooTable->search(....);
> 
> or sometimes
> 
> MyDB::FooTable->get_event_data(43);
> 
> The idea being that this class method encapsulates a certain usage of
> the method ->search() and a common transformation of the output (and
> possibly other linked actions).  In some ways it is conceptually
> similar to an inflate_column kind of thing, but more like
> inflate_results.  The reason it's inside the table class instead of
> just a common subroutine within the application is because the
> functionality offered isn't really application or representation
> -specific, it has general applicability for anyone who might use my
> Schema (much like a Stored Procedure in that way).
> 
> If I make this a class method in a Schema "package My::Schema::Foo;
> sub get_event_data { ... }", can I call it as
> "$schema->class('Foo')->get_event_data(43);", and will the
> $self->search() within this class method even work correctly (or would
> it need to be like $self->schema->resultset('Foo')->search())?

I'd stick 'em on a custom ResultSet subclass.
 
> I'm lost :)  I don't mind refactoring/rewriting any table-method code
> I'm currently using in my old /bad way of doing things in order to do
> things the Schema way, I'm just not sure where such things should land
> or how.  Conceptually, to me, they belong in/with whatever class
> defines this table.

I've been wondering whether it might not be cool to have something where
during creation, a ResultSource will check to see if (for a result_class
of MyDB::Foo) there's a MyDB::FooSet class, and if so use that as its
default resultset_class instead of DBIx::Class::ResultSet.

But I dunno, and there's about 3 million different possible naming
convention you could use, which leads me to expect either a holy war or
needing to implement something like RDBO's ConventionManager if I try it.

Anybody got any suggestions?

-- 
     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/ +