[Dbix-class] has_many LEFT JOIN with parameter

[Peter Rabbitson]

On Mon, May 09, 2011 at 09:04:52AM +0100, Ton Voon wrote:
> 
> On 6 May 2011, at 19:10, Justin Hunter wrote:
> 
> > Per http://search.cpan.org/dist/DBIx-Class/lib/DBIx/Class/Relationship/Base.pm#condition, under "To specify joins which describe more than a simple equality of column values, the custom join condition coderef syntax can be used. For example:"
> > 
> > __PACKAGE__->has_many(
> >     "useraccounts", "UserAccounts"
> >      sub {
> >       my $args = shift;
> > 
> >       return {
> >         "$args->{foreign_alias}.userid" => { -ident => "$args->{self_alias}.id" },
> >         "$args->{foreign_alias}.accountid"   => { '=', $value },
> >       };
> >     }
> >   );
> > 
> > not sure where the join_type will go, but that should be the gist. 
> 
> Thanks Justin. I wasn't aware of this functionality.
> 
> It is close, but not quite there. I think I want the example of:
> 
> My::Schema::Artist->has_many(
>     cds_80s => 'My::Schema::CD',
>     sub {
>         my $args = shift;
>         return {
>             "$args->{foreign_alias}.artist" => { -ident => "$args->{self_alias}.artistid" },
>             "$args->{foreign_alias}.year"   => { '>', "1979", '<', "1990" },
>         };
> 
>     }
> );
> 
> ... but where the 80s is dynamically entered at search time. Maybe something like:
> 
> $schema->resultset("Artist")->search( { name => "Elton John" }, { join => { "cds_decade" => { "-params" => [ "1979", "1990" ] } } })
> 
> Is this a useful feature? If so, I'm happy to have a go at this if someone can point where this change should be.
> 

This is a useful feature, the lack of which affected the decision to not ship
0.08200 (but instead stick to the 1xx series a bit longer). Also it's a very
complex task in its early design stages. The problem is that the surface of
the API is getting quite crowded, and we can easily paint ourselves into a
corner if we are not extremely careful. For this particular feature there
are the following obstacles to consider (all of them have seen some but not
enough progress)

 - what happens to create_related and friends
 - the current join/prefetch spec merging mechanism does not have a concept
   of options
 - more stuff I have not yet thought of :)

That said you are welcome to experiment/sketch things, all I am trying to say
is that this is not a 15 minute task, and to make things worse there's a lot
of pressure to get things just right before we reach the physical limits of
DBIC as conceived back in 2005.

Also as a quick and dirty hack you can very well define your relatinship as
 sub { .... foo => $some_class_global ... }
and simply ensure that you have it set during operations (perhaps by executing
some sanity-checks in the very same relcond sub).

I am on hiatus this month, so won't be able to offer much guidance/advice on
potential improvements, but feel free to poke the rest of the wonderful
folk in #dbix-class

Cheers!