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

Henry Drinkwater henry.drinkwater at googlemail.com
Tue Jul 15 06:48:46 BST 2008

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

> 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=
>>>>> foreign and self columns. To give an example, suppose I have two tabl=
>>>> I too would love to be able to do this.
>>>>> but couldn't find anything that worked - I get an exception thrown li=
>>>>> 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 =
>>>> 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,=
>>> I'm sure the core maintainers would love to have somebody take a crack =
>>> 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=
> True, it's more of a business condition, unless you consider a polymorphic
> relationship to be a "true" relationship. Consider this (simplistic) exam=
> (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').=
> 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=
> 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=

More information about the DBIx-Class mailing list