Here is the scenario:
1. I get some data with a find query and flatten the data.
2. I run this through the Javascript->object(...) to obtain the JSON
string.
First, a simple schema for the data:
id: integer
name: string
donation: decimal(13,2)
created: datetime
modified: datetime
What I get back looks something like this:
[ { 'id': 1, donation: "100.00", created: "2008-01-01", modified:
"2008-01-01"}, ... ]
Notice the donation is quoted as if it's a string. This is a result of
the function value in the Javascript helper. It uses a test case of
is_float($val) to determine if a value is a float. This function does
not evaluate strings as floats, even if they pass is_numeric(...).
This is well documented in the php manual.
The reason for this is the mysql driver returns all data as wither
String or NULL. So even though the data is decimal, it returns it as
type string in the result array. This posses a problem for anyone who
wants to JSON data returned from MYSQL (or Postgres for that matter,
not sure about other php db drivers...).
So, knowing this I decided to try patching the Javascript helper to
cast a bit more intelligently. I replaced the "case (is_float($val)):"
in the function value(...) with "case (is_numeric($val) && (float)$val
== $val):" and got my desired behavior. Great, fantastic, swell!
No problem, when I run the helper over it's unit tests I get a failure
on the test where a number is quoted. It expects "1" to be JSON'ed as
a string and not a float (incidentally, you can change the case for
integer to a similar syntax so it converts it to an int at least, but
it still fails the test). From the revision history, this was done to
more fully support the JSON standard. The unwanted side effect is that
php's lose typing makes a scenario where nearly every value in an
array is going to be string quoted.
Possible solutions would be to be slightly less strict in our
Javascript->value(...) function as I have already tried. Update the
unit test and be done with it. Another possible route is to cast
returned database values based on the schema. That would probably
require a significant change to the dbo code, but could possibly work.
The exception being that php floats are not accurate, so you'll likely
loose precision compared to what the database has (which is actually
why I believe they return strings in the first place...).
One other solution that may work is to add an option to the Javascript-
>object(...) function to be less strict on converting values. The
regular rules would apply for forced quotes anyways, so this would
seem like the most "backwards" compatible solution. I'll likely write
up a patch that reflects this approach this afternoon.
Idea's and alternate solutions would be great to hear.
James
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"CakePHP" group.
To post to this group, send email to cake-php@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/cake-php?hl=en
-~----------~----~----~----~------~----~------~--~---
