Skip to content

Commit

Permalink
Fixing bug where scientific notations were not passed to mysql in the…
Browse files Browse the repository at this point in the history 
…ir original form which resulted in loss of precision
  • Loading branch information
Jelle Henkens committed Sep 5, 2011
1 parent 15a1741 commit 53d221c
Show file tree
Hide file tree
Showing 2 changed files with 23 additions and 4 deletions.
2 changes: 1 addition & 1 deletion cake/libs/model/datasources/dbo/dbo_mysql.php
View file
Expand Up @@ -672,7 +672,7 @@ function value($data, $column = null, $safe = false) {
return 'NULL';
}
if (is_float($data)) {
return sprintf('%F', $data);
return str_replace(',', '.', sprintf('%G', $data));
}
if ((is_int($data) || $data === '0') || (
is_numeric($data) && strpos($data, ',') === false &&
Expand Down
25 changes: 22 additions & 3 deletions cake/tests/cases/libs/model/datasources/dbo/dbo_mysql.test.php
View file
Expand Up @@ -239,14 +239,33 @@ function testLocalizedFloats() {
setlocale(LC_ALL, 'de_DE');

$result = $this->db->value(3.141593, 'float');
$this->assertEqual((string)$result, '3.141593');
$this->assertTrue(strpos((string)$result, ',') === false);

$result = $this->db->value(3.141593);
$this->assertEqual((string)$result, '3.141593');
$this->assertTrue(strpos((string)$result, ',') === false);

$result = $this->db->value(2.2E-54, 'float');
$this->assertEqual('2.2E-54', (string)$result);

$result = $this->db->value(2.2E-54);
$this->assertEqual('2.2E-54', (string)$result);

setlocale(LC_ALL, $restore);
}

/**
* test that scientific notations are working correctly
*
* @return void
*/
function testScientificNotation() {
$result = $this->db->value(2.2E-54, 'float');
$this->assertEqual('2.2E-54', (string)$result);

$result = $this->db->value(2.2E-54);
$this->assertEqual('2.2E-54', (string)$result);
}

/**
* testTinyintCasting method
*
Expand Down

1 comment on commit 53d221c

@default007
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This fix, that seems to be good for scientific notation, actually spoiled my non-scientific floats...

If I want to store a number like 6117.2830435934, CakePHP actually rounds it off without considering the schema. That's bad. But at least before, with %F, the loss of precision was not so dramatic, as it chopped it to 6117.283044, that was good enough for my FLOAT(11,4) precision in the database.

But now, when using %G, it actually writes 6117.28, with an enormous loss of precision!

So it is a bad fix for my case, and I had to revert it after the last upgrade to 1.3.12, as my tests started to fail. Maybe everyone would be happy if you used %E instead...

Compare these outputs (in PHP 5.3.2-1ubuntu4.9):

sprintf("%F", 123456.2345678901) -> 123456.234568
sprintf("%G", 123456.2345678901) -> 123456
sprintf("%E", 123456.2345678901) -> 1.234562E+5

sprintf("%F", 1234567.2345678901) > 1234567.234568
sprintf("%E", 1234567.2345678901) -> 1.234567E+6
sprintf("%G", 1234567.2345678901) -> 1.23457E+6

If CakePHP is not going to look at the schema to find out the desired precision, then this sprintf should use by default the maximum precision possible. (?)

I wanted to report a bug, but lighthouseapp is down: http://twitter.com/#!/lighthouseapp/status/121591724710707201 I'm writing this here temporarily, to keep the information somewhere.

Please sign in to comment.