Deprecate passing parameters to Statement::execute*()

[morozov]

Q	A
Type	deprecation

Being able to bind parameters to the statements via execute($params) is a PDO legacy and has the following downsides:

1. Unlike the Statement::bindParam() and ::bindValue() methods which accept 1-based numeric parameter positions, execute($params) expects 0-based indexes for positional parameters. This results in the inconsistency in logging statement parameters as reported in Inconsistent parameter indexes passed to the logging middleware #5525.
2. No way to tell statically whether the $params in a given call to Statement::execute() should have integer or string keys since it depends on how parameters were declared in the SQL used to prepare the statement.
3. The behavior of passing $params to execute() of a statement that already has parameters bound via bindParam() or bindValue() is undefined. Do parameters get merged or the previously bound parameters get ignored?
4. The side effect of passing $params to execute() is undefined. Do the corresponding values remain bound to the statement or they are used only for this call? For reference, they remain bound to the wrapper statement but the driver-level behavior is undefined and is defined by the DBAL-level or the underlying driver.
5. Not all underlying drivers support this API, so the DBAL has to emulate it by calling "bind" internally (e.g. for oci8).

The even bigger problem is that the wrapper level uses the same API for binding positional and named parameters that results in ugly and incorrect types like list<...>|array<string,...>. Whether the statement parameters are positional or named is decided at runtime. Deprecating this feature is the first step toward introducing separate APIs for positional and named parameters.

Affected API consumers:

1. The ORM will not be affected since it minds the parameter types and uses Statement::bindValue() for binding parameters to the statement.
2. The users of the DBAL will be barely affected since the wrapper-level API will still allow using the "shortcut" methods like executeQuery($sql, $params, $types).

[mvorisek]

Isn't this exactly the oposite of simillar newly introdue php function to mysqli - php/php-src#8660?

[morozov]

No. The newly introduced mysqli_execute_query() is analogous to Connection::executeQuery() and other "shortcut" methods that this deprecation doesn't affect.

[vinceAmstoutz]

In Symfony,executeQuery() is mentionned here : Querying with SQL.

I would like to confirm the change with you, please because a deprecation appears in my case since Symfony 6.3 was released.

Deprecation : User Deprecated: Passing $params to Statement::executeQuery() is deprecated. Bind parameters using Statement::bindParam() or Statement::bindValue() instead. (Statement.php:212 called by UtilisateurRepository.php:420, https://github.com/doctrine/dbal/pull/5556, package doctrine/dbal)

Tell my if I'm wrong, we can't do this right now :

// src/Repository/ProductRepository.php

// ...
class ProductRepository extends ServiceEntityRepository
{
    public function findProductByPriceQuantityAndCategory(int $price, float $quantity, string $category): array
    {
        $conn = $this->getEntityManager()->getConnection();

        $sql = '
            SELECT * FROM product p
            WHERE p.price > :price
            AND quantity >= :quantity
            AND category = :category   
            ORDER BY p.price ASC
            ';
        $stmt = $conn->prepare($sql);
        $resultSet = $stmt->executeQuery([
             'price' => $price,
             'quantity' => $quantity,
            'category ' => $category,
        ]);

        // returns an array of arrays (i.e. a raw data set)
        return $resultSet->fetchAllAssociative();
    }
}

Do we have to use bindParam() as many times as there's a parameter to pass, or is there another way, for example by passing an array of parameters somewhere?

   [
      'price' => $price,
      'quantity' => $quantity,
      'category ' => $category,
    ]

(I haven't found anything about this particular case on DBAL/Documentation/Data Retrieval And Manipulation and DBAL/UPGRADE).

[derrabus]

There is an executeQuery() method on the connection that you can use instead.

[vinceAmstoutz]

There is an executeQuery() method on the connection that you can use instead.

Tanks 🙂@derrabus

[fmonts]

IMHO this decision is a bad decision that doesn't provide any advantage to the community.
We are forced to change code in a way that adds verbosity for nothing, for example:

(of course we could use Connection::executeQuery(), but who is used to prepared statements finds it wrong to pass the same SQL string thousands of times in a loop)

I hope an alternative will be reintroduced.

[sofigio]

You can also call getWrappedConnection() and do that with PDO, but yes it was a nice feature to have

[Evgeny1973]

What if there is a variable number of values? ($values - array with variable number of values).
$in = implode(',', array_fill(0, count($values), '?'));
Now in query
$sql = SELECT COUNT(*) AS count FROM table t <...> AND t.id IN ({$in});
$stmt = $this->connection->prepare($sql);
return $stmt->executeQuery($values)->fetchOne();
How can I do data substitution now?

[derrabus]

$sql = 'SELECT COUNT(*) AS count FROM table t <...> AND t.id IN (:ids)';

return $this->connection->executeQuery($sql, ['ids' => $values], ['ids' => ArrayParameterType::INTEGER]);