On Mon, Jul 14, 2008 at 5:18 PM, Jason Gottshall <[EMAIL PROTECTED]>
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 tables:
>>>>>
>>>> I too would love to be able to do this.
>>>>
>>>>> but couldn't find anything that worked - I get an exception thrown like
>>>>> 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 implement. 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 relationship.
>>
>
> True, it's more of a business condition, unless you consider a polymorphic
> relationship to be a "true" relationship. Consider this (simplistic) example
> (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 production()
> as an explicit method:
>
> sub production {
> my $self = shift;
> my $method = 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 = 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.
_______________________________________________
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]
