[Dbix-class] might_have join condition with value rather than column

[Henry Drinkwater]

On Mon, Jul 14, 2008 at 5:18 PM, Jason Gottshall <jgottshall at capwiz.com>
wrote:

> Ash Berlin wrote:
>
>>
>> On 14 Jul 2008, at 15:59, Jason Gottshall wrote:
>>
>>  Robert Loomans wrote:
>>>
>>>> Henry Drinkwater wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I am trying to create a might_have join condition in DBIx::Class where
>>>>> I want to add a value comparison as well as having matching values in=
 the
>>>>> foreign and self columns. To give an example, suppose I have two tabl=
es:
>>>>>
>>>> I too would love to be able to do this.
>>>>
>>>>> but couldn't find anything that worked - I get an exception thrown li=
ke
>>>>> this:
>>>>>
>>>>> Invalid rel cond val HASH(0x94a79c)
>>>>>
>>>>> for all the things I tried. Is this kind of join possible and if so
>>>>> what is the right syntax?
>>>>>
>>>> I've looked for the error in the DBIC code and it doesn't support
>>>> parsing such relations...
>>>> Is this an oversight and no-one else has had that particular itch, or =
is
>>>> there reason for not implementing it?
>>>>
>>>
>>> I raised the same issue a while back. The basic gist of the response was
>>> that it's definitely desirable but probably a little tricky to implemen=
t. I
>>> did some code diving at the time, and stopped when my head got near the
>>> exploding point. I haven't had any tuits lately to devote to the issue,=
 but
>>> I'm sure the core maintainers would love to have somebody take a crack =
at
>>> it...
>>>
>>> Jason
>>>
>>>
>> That about sums up my view on it. Also add that the fact that a static
>> condition like that isn't *technically* anything to do with a relationsh=
ip.
>>
>
> True, it's more of a business condition, unless you consider a polymorphic
> relationship to be a "true" relationship. Consider this (simplistic) exam=
ple
> (based on the one I posed back in Jan07):
>
>  Actor: id, name
>  ActorRole: actor_id, character_name, production_type, production_id
>  Film: id, title, studio, release_date
>  TVShow: id, title, seasons
>
> where ActorRole.production_type is one of "Film" or "TVShow" and
> ActorRole.production_id is the foreign key in the corresponding table.
> (Assume that the attributes of Film and TVShow are substantially different
> enough to need independent tables.)
>
> The main challenge here is to define ActorRole->belongs_to('production').=
 I
> think the best solution currently is to define both belongs_to('film') and
> belongs_to('tvshow') based on the production_id field, then add productio=
n()
> as an explicit method:
>
>  sub production {
>    my $self =3D shift;
>    my $method =3D lc $self->production_type;
>    return $self->$method;
>  }
>
> You can also explicitly define methods on Actor for the implied
> many_to_many relationships:
>
>  sub films {
>    my $self =3D shift;
>    return $self->actor_roles->search_related('film');
>  }
>
> I'm not sure if any of this helps solve the original poster's problem, but
> it illustrates the complexities of working around the fact that one cannot
> currently specify value-based conditions in relationship definitions.
>
> Jason
>
>
Thanks for the replies folks. I don't think this work around will do what I
want, because I need an outer join condition to get the results I want. I
think the only way will be to define a raw sql result set, as I don't think
I'm quite up to hacking the DBIC code to allow that sort of relationship.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/dbix-class/attachments/20080715/1d5=
e5136/attachment-0001.htm