[Dbix-class] PATCH: Support for arbitrary SQL in relationship definition

Peter Rabbitson rabbit+dbic at rabbit.us
Tue Jun 30 15:56:32 GMT 2009


David Ihnen wrote:
> Peter Rabbitson wrote:
>> David Ihnen wrote:
>>   
>>> Ivan Fomichev wrote:
>>>     
>>>> Hello, great module. Instead of arguing if it is a useful patch or not
>>>> and if it should be applied or there are weird workarounds easily
>>>> available, just make your own DBIx::Class component and release it on
>>>> CPAN. Who need will load this component. Good luck. Ivan.
>>>>   
>>>>       
>>> Can you even DO that in a component?
>>>
>>> Essentially you're suggesting writing your own DBIx::Class::Relationship?
>>>
>>> The thought makes my eyes water.
>>>
>>>     
>>
>> And you on the other hand are suggesting that we include *some* support,
>> no matter how well thought through (or not). 
> That the feature is well thought out is important I agree.
>> I stand by my criticism, that
>> the only sql-in-scalarref we could responsibly publicize is the virtual
>> view construct, which is built for this very purpose. Problem of course is
>> that the view definitions (virtual or not) are static, i.e. we can't push
>> placeholders into the join condition.
>>
>> So really this discussion is coming down to: "A call for relationship
>> attribute proposals to specify query-time join conditions, harnessing the
>> full power of SQLA"
>>
>>   
> 
> But the question seemed to be 'I don't understand why you would need
> this' and 'is there a need for this feature' and I must vociferously
> respond "IT IS USEFULE" and "YES THERE IS".  As for 'is there a need to
> do it this way' to which I'd agree with you, probably not this way, its
> awfully cludgy to use the refs.
> 
> BTW, I am okay with the join terms *not* being query time
> dynamic/bindable stuff - in my application I want to join based on two
> separate relations between the two tables, not just one, and not using a
> query-time parameter that affects the relationship spec.
> 

This is available in official versions *today*. The synopsis of [1] shows
*exactly* what you want to do. Note that is_virtual(1) will keep it from
littering the database as well.

P.S. A good payment for this advice would be a cookbook entry diff :)

[1] http://search.cpan.org/~ribasushi/DBIx-Class-0.08107/lib/DBIx/Class/ResultSource/View.pm



More information about the DBIx-Class mailing list