[Dbix-class] binding variables to CASE WHEN

[Peter Rabbitson]

On 04/08/2015 08:52 PM, Augustus Saunders wrote:
>
> On Apr 8, 2015, at 5:03 AM, Dagfinn Ilmari Mannsåker <ilmari at ilmari.org> wrote:
>
>> As explained in the Cookbook, you can pass the \[] directly to
>> ->search(), or use { -and => [\[...], ...] } if you wish to combine it
>> with other conditions:
>>
>> https://metacpan.org/pod/distribution/DBIx-Class/lib/DBIx/Class/Manual/Cookbook.pod#Using-SQL-functions-on-the-left-hand-side-of-a-comparison
>
> 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.
>
>> When I said "doesn't work" I wasn't talking about situations wher perl
>> doesn't let you put a reference (e.g. hash keys), but places where DBIC
>> accepted it, but did the wrong thing.
>
> Let's say then that \[] is insufficient for all your variable binding needs due to Perl limitations.

Let's elaborate on this? Going forward \[] is the only supported way of 
doing sql+bind passing, any issues with it need to be fixed.


>> Or are you talking about using \'' with placeholders and sticking the
>> parameters in the 'bind' attribute yourself?
>
> So count gets confused if you use bind => []

Yes, because bind (the rs attribute) is nothing more of "Put these 
pieces *indiscriminately* before the FROM clause bind values". It is 
true this is not clearly documented, putting down a note to have an 
overhaul of this section.

But the actual behavior is consistent with how bind[] was originally 
"designed" - i.e. it is an entirely stateless, low-level tool. This is 
why the \[] variant was devised and everything refers to it these days. 
Also note that if the patches you are working on alter the current 
behavior of the bind attribute it is exceedingly unlikely that I will be 
able to accept them.