[Dbix-class] binding variables to CASE WHEN

Augustus Saunders asaunders at solfo.com
Wed Apr 8 20:36:19 GMT 2015


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.

The example presents special casing a scenario that doesn't need it and is overly confusing for such a simple use case. It works, but {'column_expr' => $val}} or {'column_expr' => {op => $val}} is the more natural and obvious way to accomplish that task.

>> 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.

I don't know that there are issues with \[], just as discussed Perl prevents us from using that everywhere we might want it. If DBIx could expose an alternate structure like:

{
	LHS => \[],
	op => whatever,
	RHS => \[]
}

that would work around the Perl limitation. But I think that's all handled by SQL::Abstract, so I'm not sure what's realistic here.

Also, we use bind in our codebase quite a bit, in particular with DBIx level views. I don't see an obvious way to eliminate that necessity. As we figure out how to use DBIx and SQL::Abstract better, we are reducing the need for custom SQL views, but there are still many SQL features unsupported by DBIx/SQL::Abstract that require this.

>> 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.

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.

Thanks-
Augustus


More information about the DBIx-Class mailing list