Query error with parameterised queries about phpstan-dba HOT 9 CLOSED

Yes, thank you (once I realised that composer was not updating).

from phpstan-dba.

for some reason the placeholder replacement does not work on your machine.
I cannot reproduce either in CI nor on my windows laptop.

could you dig a bit thru

to get a feeling why it fails in your setup?

from phpstan-dba.

I was able to reproduce this problem, when

    -
        class: staabm\PHPStanDba\Rules\SyntaxErrorInQueryMethodRule
        tags: [phpstan.rules.rule]
        arguments:
            classMethods:
                - 'rex_sql::setQuery#0'
                - 'rex_sql::setDBQuery#0'
                

is configured for a method, which actually takes a prepared statement and query-string separately

from phpstan-dba.

I think we are on the same page... and Pull Request 119 has stopped the error.

From my understanding, the checking of $pdo->prepare() does not call replaceParameters(), so the SQL is sent to the database with the placeholders (causing it to error).

In comparison $stmt->execute() (which is checked after this error has happened), does use replaceParameters(), and is fine.

I'm just wondering, could the parameters simply be replaced with the number 0? something like this:

$queryString = preg_replace('/(\?|\b:[a-zA-Z0-9_]+\b)/', '0', $queryString);

It's already using LIMIT 0, so it won't return any records... but I must confess I've not really checked it, and this approach might cause other issues.

e.g. While these are a bit contrived, WHERE question LIKE "%?" or WHERE meta_data LIKE "%:tag_name%". Because I'm not really doing proper parsing of the SQL string, those characters would be incorrectly replaced because they look like placeholders.

As an aside, I think there might have a similar issue with countPlaceholders() and extractNamedPlaceholders().

I wonder, if this is a problem, does it needs to do something similar to the pdo_parse_params() function, rather than simply using the BINDCHR regex (used later as PDO_PARSER_BIND)... as that supports escaped question marks (??), comments (/* What about X? */ or -- To fix?), and quoted string values (if I'm reading this correctly, using ANYNOEOF?).

from phpstan-dba.

You are right that the current parsing is a bit naive and can easily break in edge cases.

We might finally use a proper sql parser.

Regarding your inital problem: I guess your phpstan-dba config is wrongly mixing SyntaxErrorInPreparedStatementMethodRule and SyntaxErrorInQueryMethodRule.

Actually for pdo support you don't need additional rules configuration. The default config should work for pdo-only source analysis.

I'm just wondering, could the parameters simply be replaced with the number 0

Thats what SyntaxErrorInPreparedStatementMethodRule is doing when variables types are known:

from phpstan-dba.

Just running a quick test (need to go in a bit)... I've used a script that only contains:

<?php

$pdo = new PDO('mysql:dbname=test;host=localhost', 'test', 'test', [PDO::ATTR_EMULATE_PREPARES => false]);

$stmt = $pdo->prepare('SELECT * FROM user WHERE id = ?');

And that triggered the 'Query error' in SyntaxErrorInQueryMethodRule.

Taking a guess, that might be due to the provided dba.neon file.

from phpstan-dba.

Just running a quick test (need to go in a bit)... I've used a script that only contains:

<?php

$pdo = new PDO('mysql:dbname=test;host=localhost', 'test', 'test', [PDO::ATTR_EMULATE_PREPARES => false]);

$stmt = $pdo->prepare('SELECT * FROM user WHERE id = ?');

And that triggered the 'Query error' in SyntaxErrorInQueryMethodRule.

Taking a guess, that might be due to the provided dba.neon file.

I think this example works on latest master. I think it was fixed with #119

at least running your example in a unit test seems to not produce a error, see #124

from phpstan-dba.

Yep, when I used #119, that fixed the error... and I suspect those checks are run when it get's to the $stmt->execute() (sorry, gtg, and I'm probably not going to be available for a few days).

from phpstan-dba.

Does the initial issue still reproduce or can we close the issue?

from phpstan-dba.