-
Notifications
You must be signed in to change notification settings - Fork 375
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
Fixed error when using PDO::ATTR_STRINGIFY_FETCHES #1468
Fixed error when using PDO::ATTR_STRINGIFY_FETCHES #1468
Conversation
… after 8.2.9 php version
85b09d1
to
3651a6e
Compare
Why does this PR change nothing? |
A test was crashing unexpectedly, so I'm temporarily running it without any changes. |
… after 8.2.9 php version
The tests seem to fail even without any changes, and there seems to be some unstable tests. |
@v-makouz |
This test will fail even if I didn't make any changes. I don't understand why this is the case, just by looking at it lightly. |
Thanks for your contribution, there're some tests may fail intermittently due to connection. I'll rerun it. |
Thank you for confirmation. Am I correct in thinking that I have to rerun the connection test many times until it succeeds? |
Hi, I heard PHP 8.1.22 and 8.2.8 throws Exception when Regards. |
I have merged this PR, it'll be included in the next release. |
Thank you for confirming and merging! |
Are there perhaps some undocumented changes coming, or was it a bug and no changes intended? |
Yes, it is. This is a fix that removes the error caused by changes in PDO core. |
I also got hit with this issue, thanks for the PR and the merge! |
#Hi, I have also :
I tried everything, removing all PDO::ATTR or PDO::SQLSRV, and the result is the same! Here is a sample of the connection data:
I also tried upgrading to PHP 8.2.8 and the result is the same. The only way it worked, was downgrading to PHP 7.4 and I make a simple PHP script to test db connection and works, but this is not a solution for me, because I have a lot of composer dependencies for PHP 8.1 and I can't downgrade it! will be a messy job and some app features will be broken. Can anybody help/guide me to the solution to this problem? |
Is it really php8.2.8? |
Sorry, it was my mistake... I put in PHP 8.2.8 and re-install the driver and now it works !!! in PLESK if you change the PHP version you have to install again the driver, even if you have it in 8.2.0. Now my question shifted...what will happen if PLESK auto updates and forces us to use PHP 8.2.9 or + ? Is this a temporary fix? |
This fix is still in the process of being merged into the dev branch and has not been released. It will be included in the next release. If you update to php8.2.9 again before the release, of course the problem will reoccur. Using the driver that is new version after release will permanently fix this issue. |
@pirex360 In my own limited experiment and testing, it is safe to remove this line. Please correct me if I am wrong. This is also a solution wrote by SakiTakamachi using a try catch block without removing |
Yes, you are right. In the current php specification, the initial value of Therefore, it can be controlled by specifying You can safely delete the |
"after release" 😞 |
@SakiTakamachi |
It's weird, In my testing... I remove all the options array from the connection :
And still, the error appears... |
It doesn't make much sense to test it in Laravel. Because the initial value is set inside Laravel, it is not possible to completely remove the option specification. |
And removing an option doesn't mean setting it to false, it means not specifying anything. |
Sure, You are right... it fallback to the defaults... but doesn't the default supported by the driver? Thanks for your time, it was enlightenment. |
@absci Any news on when the next release will take place? |
There's no exact time at the moment, possibly the end of 2023. |
Is it difficult to release a patch version that addresses this issue as 5.11.1 first? |
I'll discuss it with management levels. Maybe we can do a hotfix release. |
I apologize for the trouble. |
This is currently breaking the build process for my company. Since we build our container off Ubuntu using Ondrej repo we are stuck on PHP 8.1.22 that has this problem. So a hotfix would be a godsend to getting this resolved. Also thanks @SakiTakamachi for a good job finding and fixing this. |
Since this is currently breaking every single Laravel install where the developer is unable to control the minor version of PHP (e.g., Plesk-hosted – once you’re on 8.2.9, it seems you can’t downgrade back to 8.2.8 without Plesk auto-re-upgrading), a hotfix would be highly appreciated. |
For those of you with a Laravel installation also suffering from this problem at the moment - the workaround suggested here helped us to circumnavigate that issue for now. Anyhow, a release of this fix would be highly appreciated. |
Here is the easiest und final solution: install it and the problem is gone. |
Not a final solution, just a bandaid. Basically just ignores the problem this driver is currently causing. The final solution would be to get a patched version of msphpsql. I have over 25+ services so manually installing this bandaid until this is fixed then removing it is quite a large effort. |
Think this PR should not have been merged as-is. The fix should be made in PHP (the offending PR should be reverted), where the break happened. This change will be fine if it is needed for PHP 8.3. But don't make everyone else patch out-of-band for an upstream error. Changes that break backwards compatibility should only be made on version changes where you might expect to have to test for version compatibility. Upgrading from PHP 8.2.8 to PHP 8.2.9 shouldn't break downstream apps. |
All other pdo exts do not raise an error under the same conditions. Only PDO SQLSRV raises an error. So I personally don't think this is a BC break. It takes a lot of effort to consider all downstream proprietary specifications in order to make upstream modifications. I have checked all 16 pdo drivers present in pecl and only sqlsrv causes the error, even those not in php-src. |
Even if you look at the PDO documentation, it doesn't say that setAttribute throw an exception, and it states that it simply returns https://www.php.net/manual/en/pdo.setattribute.php#refsect1-pdo.setattribute-returnvalues Therefore, I believe that the essence of this problem is that PDO SQLSRV does not conform to the PDO specification. |
@David-Engel No, I don't think PHP 8.2.9 is BC break. Because this is done for the convenience of throwing parameters other than the allowed list that msphpsql is doing arbitrarily. I think should fix to msphpsql. |
@David-Engel Or are you saying that you don't allow modifying ext/pdo/pdo_dbh.c in php-src? |
I think one thing, If msphpsql isn't going to chase php-src, it should be proposed in an RFC to have it integrated into php-src. |
@David-Engel |
I have created an issue because I can't keep talking forever in this PR. |
* fix accept PDO_ATTR_STRINGIFY_FETCHES to set_attr on after 8.1.22 and after 8.2.9 php version * try to put it back * fix accept PDO_ATTR_STRINGIFY_FETCHES to set_attr on after 8.1.22 and after 8.2.9 php version
This fixes the issue reported here.
laravel/framework#47937
Fixes for errors caused by PDO changes in php8.1.22 and 8.2.9.
test code