Marco Pivetta
added a comment - 16/Apr/13 7:58 AM First failure I can see is at https://travis-ci.org/jackalope/jackalope-doctrine-dbal/jobs/6347501 - is there any other relevant failure before that one?

UPDATE phpcr_nodes SET sort_order = CASE CONCAT(
namespace,
(CASE namespace WHEN '' THEN '' ELSE ':' END),
local_name
) WHEN :name0 THEN :order0 WHEN :name1 THEN :order1 WHEN :name2 THEN :order2 WHEN :name3 THEN :order3 WHEN :name4 THEN :order4 ELSE sort_order END WHERE parent = :absPath

David Buchmann
added a comment - 17/Apr/13 11:15 AM are we doing something wrong or is this a regression in dbal?
should we for now force an older version of doctrine-dbal? (this would be annyoing however, as we would run into version conflicts with doctrine-commons then i think)

I think the problem here is the ':' on the parameter key, which i'm not sure if are suported for DBAL.
Before #DBAL-488 it does not apply 'SQLParserUtils::expandListParameters' for parameters without types.

Fabio B. Silva
added a comment - 18/Apr/13 1:49 PM - edited I think the problem here is the ':' on the parameter key, which i'm not sure if are suported for DBAL.
Before # DBAL-488 it does not apply 'SQLParserUtils::expandListParameters' for parameters without types.

Fabio B. Silva
added a comment - 20/Apr/13 5:43 PM Benjamin, Not sure if we should consider this one related to # DBAL-488 .
It just show us another unsupported/unexpected behavior.
Actually, it will keep failing with any parameter key starting with ':' when types are given.
For instance :
$query:
SELECT * FROM foo WHERE bar = :bar
$params:
array(':bar'=>'Some String ')
$types:
array(':bar'=>\PDO::PARAM_STR)