On Wed, Jun 10, 2009 at 16:23, Daniel Ruoso<[email protected]> wrote:
> Hi,
>
> For some reason this patch is sitting on my local git copy for a while,
> and now I'm not sure it was even sent at some point... /me--
>
> So, here goes a patch against current 0.08 trunk to support arbitrary
> SQL in the join condition with an included test, which allow something
> like:
>
> __PACKAGE__->has_many(
> cds_90s => 'DBICTest::Schema::CD',
> { 'foreign.artist' => 'self.artistid',
> 'foreign.year' => \"LIKE '19%'" }
> );
I've been thinking about this for a while, then I forgot to reply
until ribasushi poked me about it.
I understand the desire to build something like this. Everyone wants
everything to be accessible from everywhere. Here's my problem:
A relationship is nothing more than the following:
* An installed method that generates a resultset
* a piece of metadata used by search() and update() to do automagical things
Your cds_90s example could be better written as follows:
sub cds_decade {
my $self = shift;
my ($decade) = @_;
return $self->cds({
year => { like => "19$decade" },
});
}
sub cds_90s { shift->cds_decade( '90' ) }
Unless, of course, you actually want to join on cds_90s, in which case
you might be better served to use a subquery in your join clause.
Now, I'm not arguing that it shouldn't be done. However, I'm still
trying to understand the usecase-space. APIs are forever - while we
have workarounds, it behooves us to think things through.
Rob
_______________________________________________
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/[email protected]
