Skip to content

Loading…

DBAL-496: "Undefined index" errors when using prepared statements #1698

Closed
doctrinebot opened this Issue · 9 comments

2 participants

@doctrinebot

Jira issue originally created by user @lsmith77:

Since a few days we are seeing errors like this in the Jackalope Doctrine DBAL test suite when using prepared statements:
https://travis-ci.org/jackalope/jackalope-doctrine-dbal/jobs/6350278#L117

@doctrinebot

Comment created by @ocramius:

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?

@doctrinebot

Comment created by @ocramius:

The notice is thrown in in Doctrine\DBAL\SQLParserUtils::expandListParameters

Can be reproduced with parameters:

$query:

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

$params:

array(
    ':absPath' => '/topic',
    ':name0' => 'page3',
    ':order0' => 0,
    ':name1' => 'page1',
    ':order1' => 1,
    ':name2' => 'page2',
    ':order2' => 2,
    ':name3' => 'page3',
    ':order3' => 3,
    ':name4' => 'page4',
    ':order4' => 4,
)

$types:

array()
@doctrinebot

Comment created by dbu:

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)

@doctrinebot

Comment created by dantleech:

Seems this is caused by: 64647f9

@doctrinebot

Comment created by @FabioBatSilva:

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.

@doctrinebot

Issue was closed with resolution "Fixed"

@doctrinebot

Comment created by @beberlei:

Reverted in master and 2.3

@doctrinebot

Comment created by @FabioBatSilva:

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:

@doctrinebot

Comment created by lstrojny:

Here is a successor for the fix from PR 301, @Fabio, could you test that with your code base: #309

@doctrinebot doctrinebot added the Bug label
@beberlei beberlei was assigned by doctrinebot
@doctrinebot doctrinebot added this to the 2.3.4 milestone
@doctrinebot doctrinebot closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.