-
-
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
[2.12] PHP 8 compatibility #4347
Conversation
f0daabc
to
dc3c262
Compare
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.
Nice! Please add some CI jobs to make sure the PHP 8 code is covered
Do you already have CI jobs for php 8 for higher branches that I could backport? |
We have some, but for Travis, and as you may know I just merged #4310 . I still need to merge it into 3.0.x. Until then, no GA jobs to backport, sorry! |
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.
This is a good idea, i was under the impression its impossible, tried my share of things but didn't come up with this workaroud :)
It would reduce a lot of the pressure to have PHP 8 support in DBAL 2.x already, we started on work for DBAL 3 in ORM 2.8, but its probably a long stretch to finish that in 6 weeks, including all the other parts of the ecosystem (fixtures, migrations, DoctrineBundle, Laminas module etc...)
As for the phpcs violations, a few have to be ignored here to disable our strict standard.
e4d4343
to
9e1dfe3
Compare
PHP CodeSniffer is happy now, but I need some help with silencing Psalm. I'm unfamiliar with the configuration of that tool. 😓 |
7d943ff
to
a1f8942
Compare
CI jobs on php 8 with SQLite, MySQL and Postgres were successful. I've tried to enable DB2 and MSSQL as well, but apparently the corresponding php extensions are not ready yet. |
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.
Is there a need to have an individual implementation for each version? As far as I understand, the underlying logic doesn't need to change, only the method signatures do. In this case, it should be possible to have the logic implemented in one trait and extended by two others which defined the expected signature.
I see that PHP 8 has been added to some build jobs but not to all of them ( |
I plan to release On the other hand, this change itself is significant enough and not a bug fix that it may deserve another unplanned minor release. |
I pushed a commit showing how to ignore one of the errors. You can run |
As I wrote earlier, I tried to enable the SQL Server tests, but the extension did not compile properly. Same for DB2. MariaDB shouldn't be a problem since the MySQL tests are working already. I've giving it a try. I'll look into Oracle as well.
I wouldn't make this a blocker for this PR. As soon as the extensions are ready, they can be added to the CI. |
1c9ad91
to
d417c8f
Compare
Agreed, let's not make it a blocker, your code is already covered by the jobs you added. |
Sutting up the OCI8 extension did not work either. I don't know if this is actually a problem of the GitHub action that is used to setup PECL extensions or if the extensions themselves don't compile yet. But that's something that could be done in a follow-up PR. But the good news is: MariaDB is tested with php 8 now. :-) |
I am unfamiliar with your versioning policy. Personally, I think releasing this as a 2.11 bugfix should be fine. But if you want to bump to 2.12 because of this change, I'm also cool with it. |
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.
Code-wise looks good now. A couple of notes are still remaining.
bdaceb5
to
03600c2
Compare
03600c2
to
a3135e2
Compare
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.
Looks good 👍 @beberlei has to give his approval as well since he requested some changes initially.
Thanks @derrabus! |
Thanks a lot @derrabus ! Awesome work! |
@morozov let's release 2.12.0 ? |
Before we release |
I will make a PR so that everyone can see the CI failures. |
Please leave a link to that PR here. |
Here you go: #4361 |
Thank you very much everyone. Having a PHP 8 compatible DBAL is great news. 🎉 |
This PR was merged into the 3.4 branch. Discussion ---------- Enable Doctrine tests on php 8 | Q | A | ------------- | --- | Branch? | 3.4 | Bug fix? | no | New feature? | no | Deprecations? | no | Tickets | #36872 | License | MIT | Doc PR | N/A Following doctrine/dbal#4347, this PR enables all Doctrine tests on php 8. Commits ------- f4a99b2 Don't skip Doctrine tests on php 8.
Release [2.12.0](https://github.com/doctrine/dbal/milestone/82) 2.12.0 ====== - Total issues resolved: **1** - Total pull requests resolved: **7** - Total contributors: **5** Documentation,Static Analysis ----------------------------- - [4376: Configuration should not be internal](doctrine#4376) thanks to @BenMorel CI -- - [4374: Reduce number of build jobs](doctrine#4374) thanks to @greg0ire - [4365: Fail on extension / tool installation failure](doctrine#4365) thanks to @greg0ire Bug,Static Analysis ------------------- - [4373: Psalm fails on release commits](doctrine#4373) thanks to @morozov Documentation,Error Handling ---------------------------- - [4362: Adds exception thrown by execute() method](doctrine#4362) thanks to @toby-griffiths CI,PHP ------ - [4361: Test all extensions with PHP8](doctrine#4361) thanks to @greg0ire PHP --- - [4347: &doctrine#91;2.12&doctrine#93; PHP 8 compatibility](doctrine#4347) thanks to @derrabus # gpg: Signature made Thu Oct 22 20:29:24 2020 # gpg: using DSA key 1BEDEE0A820BC30D858F9F0C2C3A645671828132 # gpg: Can't check signature: No public key
Summary
This PR makes DBAL 2.12 compatible with PHP 8.
The main problem with PHP 8 is that certain PDO classes have changed their method signatures in PHP 8. Since DBAL extends those classes, those changed signatures have to be applied to those child classes as well. That is of course a BC break if the calling code itself extends DBAL's classes.
With this PR, I suggest to move the affected methods into traits that exist in a php 7 and a php 8 version. This way, the BC break introduced with php 8 is handed down if and only if we're actually on php 8.
I am aware that DBAL 3.0 is supposed to become the php 8 compatible version. So why am I so eager to fix the 2.x series?
I'm really looking forward to 3.0 because it moves away from the tight coupling to PDO which makes perfect sense – especially if we look at the problem this PR aims to fix. But DBAL 3 has no stable release yet and ORM has not been migrated to DBAL 3 yet. PHP 8 on the other hand has just reached RC2 and plans the first stable release in six weeks. I really doubt that the ecosystem around Doctrine will be ready for php 8 if we make DBAL 3 a precondition for php 8.
Finally, I'd really like to test the applications I am working on with php 8 and this small change I'm proposing here unblocks me for the moment.