I’m getting strange results from the FusionTable API. Specifically, it seems unable to handle a simple select statement with equality constraints on numeric values. Any query I try of the following form:
SELECT COUNT() FROM 1Nynh5pPrj1q8JqbalppAm-qzAsgKvL0ZRala7VI WHERE AGE=41
yields zero records:
{
"kind": "fusiontables#sqlresponse",
"columns": [
"count()"
],
"rows": [
[ "0" ]
]
}
By contrast, a range constraint works fine:
SELECT COUNT() FROM 1Nynh5pPrj1q8JqbalppAm-qzAsgKvL0ZRala7VI WHERE AGE>40.99 AND AGE<41.01
{
"kind": "fusiontables#sqlresponse",
"columns": [
"count()"
],
"rows": [
[ "362" ]
]
}
Maybe the numbers underneath aren’t integers? SELECT AGE FROM 1Nynh5pPrj1q8JqbalppAm-qzAsgKvL0ZRala7VI WHERE AGE>40.99 AND AGE<41.01 returns
{
"kind": "fusiontables#sqlresponse",
"columns": [
"AGE"
],
"rows": [
[ "41" ],
[ "41" ],
[ "41" ],
...359 more...
]}
Now, maybe there’s some floating point representation error going on? I thought that small integers can be represented exactly as floats (even if some decimal fractions, e.g. 0.1, are repeating decimals in binary).
It seems unlikely that a bug in Fusion Table SQL would get by without being discovered by others, so perhaps it’s there’s something unique to how this particular FusionTable is loaded?
UPDATE:
While the query appears to fail using the new Fusion Table API above, it succeeds using the old Fusion Table SQL API (recently deprecated):
http://www.google.com/fusiontables/api/query?sql=SELECT%20COUNT()%20FROM%204579147%20WHERE%20AGE%20LIKE%2041
which returns this JSON response:
count()
362
Also, the new FusionTable API appears confused by numeric values:
-
SELECT COUNT() FROM 4579147 WHERE AGE = 41yields0(incorrect) -
SELECT COUNT() FROM 4579147 WHERE AGE = "41"yields0(incorrect) -
SELECT COUNT() FROM 4579147 WHERE AGE MATCHES 41yields362 -
SELECT COUNT() FROM 4579147 WHERE AGE LIKE 41yields362 -
SELECT COUNT() FROM 4579147 WHERE AGE LIKE "41"yields362 -
SELECT COUNT() FROM 4579147 WHERE AGE LIKE "%41%"yields362
This is a recently introduced bug that will be fixed shortly. As described it does only affect numeric equality queries with aggregation. Sorry for the inconvenience!