[5.3] bind double as PDO::PARAM_INT #16069
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
We used to have this as the code and it causes other problems. I'm sure there are GitHub threads about it. |
|
@taylorotwell I've altered the implementation to only affect MySQL connections, so only in MySQL a double will be bound as PDO::PARAM_INT |
|
Did you find the original issue I was referring to? |
|
I found this one: #14881
So I'm doing this change only on a MySQL connection since it's the one with consistency issues. |
Chekote
added a commit
to Chekote/laravel-framework
that referenced
this pull request
Jan 10, 2020
## Problem When inserting a float value into MySQL via the Illuminate\Database package when using at least PHP 7.3, the value is converted to an int. The bug has been reported a few times before: * laravel#30435 * illuminate/database#246 ## Cause PR laravel#16069 introduced logic to the MySQLConnection that cast floats to ints to address a comparison problem with JSON columns, which was reported in issue laravel#16069. This does not seem to cause a problem with PHP 7.1 and below but causes the float to lose it's decimal places when using PHP 7.3. I have not tested with PHP 7.2. ## Bug Reproduction Given we have the following MySQL table: ``` CREATE TABLE `zip_codes` ( `zip_code` varchar(255) NOT NULL, `latitude` decimal(15,10) NOT NULL, `longitude` decimal(15,10) NOT NULL ) ``` When we execute the following using Artisan Tinker: ```php DB::table('zip_codes')->delete(); // Using the same values $lat = -0.2; $lon = 0; $sql = 'INSERT INTO zip_codes (latitude, longitude, zip_code) VALUES (:lat, :long, :zip)'; // We insert the first by using PDO directly $values = [':lat' => $lat, ':long' => $lon, ':zip' => 1]; DB::connection()->getPdo()->prepare($sql)->execute($values); // Then the second by using Eloquent DB::table('zip_codes')->insert(['latitude' => $lat, 'longitude' => $lon, 'zip_code' => 2]); // Then pull them both. DB::table('zip_codes')->get(); ``` Then we should see both records with -0.2 as the latitude. But only the first has the value, and the second row is zero.
Chekote
added a commit
to Chekote/laravel-framework
that referenced
this pull request
Jan 10, 2020
When inserting a float value into MySQL via the Illuminate\Database package when using at least PHP 7.3, the value is converted to an int. The bug has been reported a few times before: * laravel#30435 * illuminate/database#246 PR laravel#16069 introduced logic to the MySQLConnection that cast floats to ints to address a comparison problem with JSON columns, which was reported in issue laravel#16069. This does not seem to cause a problem with PHP 7.1 and below but causes the float to lose it's decimal places when using PHP 7.3. I have not tested with PHP 7.2. Given we have the following MySQL table: ``` CREATE TABLE `zip_codes` ( `zip_code` varchar(255) NOT NULL, `latitude` decimal(15,10) NOT NULL, `longitude` decimal(15,10) NOT NULL ) ``` When we execute the following using Artisan Tinker: ```php DB::table('zip_codes')->delete(); // Using the same values $lat = -0.2; $lon = 0; $sql = 'INSERT INTO zip_codes (latitude, longitude, zip_code) VALUES (:lat, :long, :zip)'; // We insert the first by using PDO directly $values = [':lat' => $lat, ':long' => $lon, ':zip' => 1]; DB::connection()->getPdo()->prepare($sql)->execute($values); // Then the second by using Eloquent DB::table('zip_codes')->insert(['latitude' => $lat, 'longitude' => $lon, 'zip_code' => 2]); // Then pull them both. DB::table('zip_codes')->get(); ``` Then we should see both records with -0.2 as the latitude. But only the first has the value, and the second row is zero.
Chekote
added a commit
to Chekote/laravel-framework
that referenced
this pull request
Jan 10, 2020
When inserting a float value into MySQL via the Illuminate\Database package when using at least PHP 7.3, the value is converted to an int. The bug has been reported a few times before: * laravel#30435 * illuminate/database#246 PR laravel#16069 introduced logic to the MySQLConnection that cast floats to ints to address a comparison problem with JSON columns, which was reported in issue laravel#16063. This does not seem to cause a problem with PHP 7.1 and below but causes the float to lose it's decimal places when using PHP 7.3. I have not tested with PHP 7.2. Given we have the following MySQL table: ``` CREATE TABLE `zip_codes` ( `zip_code` varchar(255) NOT NULL, `latitude` decimal(15,10) NOT NULL, `longitude` decimal(15,10) NOT NULL ) ``` When we execute the following using Artisan Tinker: ```php DB::table('zip_codes')->delete(); // Using the same values $lat = -0.2; $lon = 0; $sql = 'INSERT INTO zip_codes (latitude, longitude, zip_code) VALUES (:lat, :long, :zip)'; // We insert the first by using PDO directly $values = [':lat' => $lat, ':long' => $lon, ':zip' => 1]; DB::connection()->getPdo()->prepare($sql)->execute($values); // Then the second by using Eloquent DB::table('zip_codes')->insert(['latitude' => $lat, 'longitude' => $lon, 'zip_code' => 2]); // Then pull them both. DB::table('zip_codes')->get(); ``` Then we should see both records with -0.2 as the latitude. But only the first has the value, and the second row is zero.
Jellyfrog
added a commit
to librenms/librenms
that referenced
this pull request
Apr 15, 2020
Jellyfrog
added a commit
to librenms/librenms
that referenced
this pull request
Apr 20, 2020
Jellyfrog
added a commit
to librenms/librenms
that referenced
this pull request
Apr 20, 2020
Jellyfrog
added a commit
to librenms/librenms
that referenced
this pull request
Apr 21, 2020
Jellyfrog
added a commit
to librenms/librenms
that referenced
this pull request
Apr 22, 2020
Jellyfrog
added a commit
to librenms/librenms
that referenced
this pull request
Apr 24, 2020
Jellyfrog
added a commit
to librenms/librenms
that referenced
this pull request
May 12, 2020
Jellyfrog
added a commit
to librenms/librenms
that referenced
this pull request
May 19, 2020
murrant
pushed a commit
to librenms/librenms
that referenced
this pull request
May 20, 2020
murrant
pushed a commit
to librenms/librenms
that referenced
this pull request
May 23, 2020
murrant
added a commit
to librenms/librenms
that referenced
this pull request
May 23, 2020
* Update Laravel core files Fix app/Http/Kernel.php * Use RouteServiceProvider::HOME * Sync Laravel default config files * Update composer dependencies to Laravel 6 * fix resources/lang/en/validation.php * Manually fixing tests required by travis, fails locally??? * Update wpb/string-blade-compiler * Add new viewany() authorization policies * Update minimum PHP version to 7.2 * Re-generate our json test-dumps Due to: laravel/framework#16069 laravel/framework#31100 * update truenas data * fix truenas Co-authored-by: Laravel Shift <shift@laravelshift.com> Co-authored-by: Tony Murray <murraytony@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR fixes this issue: #16063