[Dbix-class] binding variables to CASE WHEN

[Peter Rabbitson]

On 04/08/2015 10:36 PM, Augustus Saunders wrote:
>
> On Apr 8, 2015, at 12:13 PM, Peter Rabbitson <rabbit+dbic at rabbit.us> wrote:
>
>>> I would recommend that you don't refer people to that link, as that's generally speaking not how you want to accomplish that particular task.
>>
>> Please elaborate, also see below.
>
>  It works, but {'column_expr' => $val}} or {'column_expr' => {op => $val}} is the more natural and obvious way

... which however is a lie in terms of the API contract - you are 
telling DBIC "use the column named 'column_expr', nevermind the fact the 
column doesn't exist". Additionally you are relying on the side-effect 
of lack of quote_names, in which case most (but not all!) of the 
machinery does not check a column for existence.

So I could not disagree more with your statement "I would recommend that 
you don't refer people to that link". This is the one and only place 
people need to be pointed to when trying to do what the original poster 
asked.

"but this is ugly in perl" is not a valid argument to drive people away 
from the only universally correct solution. Please refrain from arguing 
this further in the context of new code.


> If DBIx could expose an alternate structure like:
>
> {
> 	LHS => \[],
> 	op => whatever,
> 	RHS => \[]
> }
>

This has been proposed and couldn't be made to work consistently at the 
time. However the state of the art moved on, so it may be worth taking 
another look. Noted.


> I understand that you want people to use \[], but I am unclear on why you would not want bind to work correctly in the cases it is still required.
>

It already works correctly... or am I misunderstanding the issue you are 
having...?

Can you please make a small test case using as a model 
https://github.com/dbsrgits/dbix-class/blob/current/blead/t/count/group_by_func.t#L12-L21 


Please do that *before* spending more time on attempting a fix as you 
see fit. Because if we do not agree on what needs fixing, your work will 
end up being discarded, which will be a shame.