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

[5.3] bind double as PDO::PARAM_INT #16069

Merged
merged 2 commits into from
Oct 31, 2016
Merged

[5.3] bind double as PDO::PARAM_INT #16069

merged 2 commits into from
Oct 31, 2016

Conversation

themsaid
Copy link
Member

This PR fixes this issue: #16063

@taylorotwell
Copy link
Member

We used to have this as the code and it causes other problems. I'm sure there are GitHub threads about it.

@themsaid
Copy link
Member Author

@taylorotwell I've altered the implementation to only affect MySQL connections, so only in MySQL a double will be bound as PDO::PARAM_INT

@taylorotwell
Copy link
Member

Did you find the original issue I was referring to?

@themsaid
Copy link
Member Author

I found this one: #14881

If for example a float is bound with PDO::PARAM_INT, SQLite (haven't tested with any other DBMS) will discard the decimal part (0.5 will become 0.0 in the DB). This totally broke my application.

So I'm doing this change only on a MySQL connection since it's the one with consistency issues.

@taylorotwell taylorotwell merged commit de950df into laravel:5.3 Oct 31, 2016
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
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants