-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Fix #3082: Add BC for PDO-only fetch modes #3088
Conversation
@corphi thank you for the patch. Please replicate the same logic for As for the testing, could you turn your test into a functional one so that apart from verifying the deprecation message, it also makes sure that a PDO-specific mode still works. I will help us ensure that we don't break this functionality again. UPD: at least, we need to check that the fetch mode is set as is. The deprecation notice is secondary. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nicely handled. 👍
@@ -231,7 +234,13 @@ private function convertFetchMode(?int $fetchMode) : ?int | |||
} | |||
|
|||
if (! isset(self::FETCH_MODE_MAP[$fetchMode])) { | |||
throw new \InvalidArgumentException('Invalid fetch mode: ' . $fetchMode); | |||
// next major: throw an exception |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you prefix this with TODO: ...
?
throw new \InvalidArgumentException('Invalid fetch mode: ' . $fetchMode); | ||
// next major: throw an exception | ||
@trigger_error(sprintf( | ||
'Using a PDO fetch mode (%d given) is deprecated and will cause an error in Doctrine 3.0', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The message should also mention conbination of modes:
Using a PDO fetch mode or their combination (%d given) is deprecated and will not be supported in Doctrine 3.0'
@corphi are you planning on finishing this up or I could take over? |
ee64650
to
d131c0f
Compare
@morozov I addressed the minor points raised by @Majkl578, but can’t refactor the test until Thursday. Concerning param types: I think these are a minor issue in comparison and beyond the scope of what I intended. I never used param types other than those supported by Doctrine: The native string ones are new, that basically leaves |
d131c0f
to
5562c66
Compare
No worries. I can take care of it myself. If you don't mind, I'll update this pull request. Otherwise, I'll file a new one.
I see your point and I think the same regarding custom parameters. The problem is that if somebody even in theory uses them, it will be a breaking change for them same as this one was for you. I want to get it fixed even if it's not reported. |
Other drivers (including the cache) never supported fetch modes that are not listed in `FetchMode`. Converting between the contants is only done for PDO, so BC only needs to be restored here. PDO will validate the fetch mode, we don’t have to.
78eda0a
to
8b076d8
Compare
8b076d8
to
47755a7
Compare
throw new \InvalidArgumentException('Invalid parameter type: ' . $type); | ||
// TODO: next major: throw an exception | ||
@trigger_error(sprintf( | ||
'Using a PDO parameter type (%d given) is deprecated and will cause an error in Doctrine 3.0', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we have a test for this one too? 🙏
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I cannot come up with a reasonable example. Ideas?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
PostgeSQL doesn't like PDO::PARAM_INPUT_OUTPUT
(see https://travis-ci.org/doctrine/dbal/jobs/363396885).
dbb3d1b
to
47755a7
Compare
Thanks @corphi! |
Backporting doctrine#3088 into 2.7
Backported into 2.7 @ 2cc12a1 |
This release fixes unintentional BC breaks: 1. It was impossible to use deprecated fetch modes with PDO-based drivers. 2. An unsupported option passed to the `Column` object prevented subsequent options from being applied. 3. Date interval values stored prior to upgrade to `v2.7.0` were reported as invalid. Total issues resolved: **10** **Backwards Compatibility Fixes:** - [3082: Custom PDO fetch modes and 2.7.0](doctrine#3082) thanks to @corphi - [3088: Fix doctrine#3082: Add BC for PDO-only fetch modes](doctrine#3088) thanks to @corphi - [3089: Don't skip column options.](doctrine#3089) thanks to @andytruong - [3093: When updating to version v2.7 type DateInterval throws errors](doctrine#3093) thanks to @fnagel - [3097: Fix compatibility for pre-2.7 DateIntervalType format](doctrine#3097) thanks to @Majkl578 **Documentation Improvements:** - [3083: Document the correct way of configuring a MariaDB database with serverVersion](doctrine#3083) thanks to @tristanbes - [3084: README: Add 2.7, drop 2.5](doctrine#3084) thanks to @Majkl578 **Continuous Integration Improvements:** - [3085: Tests: remove implicit verbose flag](doctrine#3085) thanks to @Majkl578 - [3090: Add symfony tests listener](doctrine#3090) thanks to @greg0ire - [3095: CI: Add missing listener for MariaDB @ mysqli](doctrine#3095) thanks to @Majkl578 # gpg: directory `/n/.gnupg' created # gpg: new configuration file `/n/.gnupg/gpg.conf' created # gpg: WARNING: options in `/n/.gnupg/gpg.conf' are not yet active during this run # gpg: DBG: locking for `/n/.gnupg/pubring.gpg.lock' done via O_EXCL # gpg: keyring `/n/.gnupg/pubring.gpg' created # gpg: Signature made Sun Apr 8 07:24:49 2018 using RSA key ID 543AE995 # gpg: Can't check signature: public key not found # Conflicts: # .gitignore # lib/Doctrine/DBAL/Driver/OCI8/Driver.php
The test case covers most of the sane PDO fetch modes that are not availably as DBAL fetch mode. Unfortunately, the fetch mode cannot be read by userland code. We have to trust that they are actually swapped for every method that uses them (well, they are); or use reflection to test the private method
convertFetchMode()
.closes #3082
Edit by @beberlei:
This deprecation was introduced as part of the removal of Doctrine DBAL API relying on implicit PDO behavior. This was started here #2958 and disallows the use of
PDO::PARAM_*
constants in Doctrine DBAL APIs.Before:
After:
in addition PDO Fetch modes that are unsupported by Doctrine explictly are disallowed, for example
PDO::FETCH_KEY_PAIR
. Use the newfetch*()
APIs instead. See #4019 for details.