Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deprecate Statement::bindParam() #5563

Merged
merged 1 commit into from Aug 4, 2022

Conversation

morozov
Copy link
Member

@morozov morozov commented Aug 4, 2022

Q A
Type deprecation

This API is a legacy of PDO and was mostly supposed to be used in two cases:

  1. Binding out parameters (e.g. to be used with stored procedures) which the DBAL doesn’t and will not support because it’s not portable.
  2. Binding variables by reference like in the following example:
    $id = 1;
    $result = $stmt->execute();
    self::assertEquals(1, $result->fetchOne());
    $id = 2;
    $result = $stmt->execute();
    self::assertEquals(2, $result->fetchOne());
    This is too low-level, archaic and error-prone. Depending on the driver, one may need to maintain a proper parameter $length in order to avoid truncation of string values (see the documentation on oci_bind_by_name() for more details). I don’t see a reason why anyone would want to do that (e.g. the ORM doesn’t).

Deprecating this API will simplify the improvements of type safety of the Statement API.

The only problem it may create is that bindParam() might be used to migrate to a better identity generation API in the ORM for Oracle (see #5443 (comment) for more details). It’s a low-priority/high-effort project, and I’m sure that if we ever get to it, we’ll find a better-localized solution.

@morozov morozov marked this pull request as ready for review August 4, 2022 13:43
@morozov morozov merged commit eb78575 into doctrine:3.4.x Aug 4, 2022
@morozov morozov added this to the 3.4.0 milestone Aug 4, 2022
@morozov morozov deleted the deprecate-bind-params branch August 4, 2022 15:57
@chetzel
Copy link

chetzel commented Apr 17, 2023

Hi Guys,

this is a horrible decision and will create huge drawbacks and work for a lot of projects. Especially calls to stored procedures are central parts for everything which goes beyond a simple web-page especially when systems have to deal with huge sets of data - you don't want to do this manually with PHP in memory and move around huge sets of data (and you'll have to pay for outgoing traffic).

A dedicated API related to storedProcedureCall(...) with typed arguments (including ParameterMode attributes like "IN"+"OUT") could easily solve this issue without interfering (simple and type save) queries, just like other programming languages/frameworks do.

If there is already a mechanism in Doctrine DBAL 4 which I might have overseen, then please tell me.

Regards, Carsten

@derrabus
Copy link
Member

A dedicated API related to storedProcedureCall(...) with typed arguments (including ParameterMode attributes like "IN"+"OUT") could easily solve this issue without interfering (simple and type save) queries, just like other programming languages/frameworks do.

If there is already a mechanism in Doctrine DBAL 4 which I might have overseen, then please tell me.

There isn't and I'll happily review this contribution. Please submit a PR. Either way, if you wish to discuss this feature further, please open a new issue for that because only a few people monitor PRs that have been closed months ago.

@frpb
Copy link

frpb commented Mar 5, 2024

We need the return value from ORACLE packages too.
We cannot work with bindValue

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants