Closed (won't fix)
Project:
Content Construction Kit (CCK)
Version:
5.x-1.6-1
Component:
number.module
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
27 Mar 2008 at 18:05 UTC
Updated:
28 Jun 2009 at 14:55 UTC
Jump to comment: Most recent file
Comments
Comment #1
rweait commentedNow with screen shots.
Comment #2
rweait commentedChanged project to Faceted_Search.
It turns out that this bug appears in CCK_Facets but is created in Faceted_Search. Sorta.
Let's review. We've created a CCK decimal field and created a facet to use it. It displays properly in guided search and works sometimes, but fails sometimes when clicking on the linked values in guided search. We create a few nodes using this and have a look at the mysql tables.
And this looks fine. So then we look at a typical query created by faceted_search.
"Empty Set"? What's that? I can see it right there, but mysql can't doesn't return it?
Sadly, float values are not always as they seem as documented here, http://dev.mysql.com/doc/refman/5.0/en/problems-with-float.html and here, http://74.54.63.139/tutorials/php/floating-point-comparisons-in-php-and-...
Adding a little bit of 'slack' to the query does find the node we're looking for like this.
So what is the best way to resolve this? Do we add some 'slack' to the queries? Ask users to specify number of decimal places and add slack at decimalplace+1? Avoid using decimal and use text values instead?
What is a reasonable way to proceed?
kbahey at 2bits found and diagnosed the problem and I am very grateful to him.
Comment #3
david lesieur commentedThanks for the investigation!
The problem is really in CCK Facets, since it is where the number comparison is added into the query. As explained on the page you have pointed to, we should probably define an acceptable tolerance for differences between the numbers and then do the comparison against the tolerance value.
This could be done in cck_facet_category::build_results_query(). The tolerance would thus be applied to all floating-point number comparisons, although I'm not sure yet if that's what we want...
Comment #4
kbahey commentedDavid
I think the problem is storing values as floats.
Just to test this, here is what I did:
Before:
So, I changed it to decimal to see what the effect would be:
And the result is:
After that, faceted search and cck facets worked perfectly on whole numbers and fractions.
So, I think storing the numbers as decimals will solve this. The issue is that this is at the cck level, not faceted search nor cck facets.
Look here http://groups.drupal.org/node/8574 and search the page in your browser for "float". Perhaps we can comment there?
Comment #5
david lesieur commentedGreat find! On the page you are pointing to, Karen says that D6 CCK offers both decimal and float types, so it looks like we'll still have to deal with floats...
Comment #6
rweait commentedAnd so we'll want to present a UI for the selection of decimal places in DEC and the tolerance or rounding amount for FLOAT. Can we drag Karen and other interested parties into this discussion? (Should that be here?)
Comment #7
david lesieur commentedApparently, D6 CCK already provides the necessary UI for selecting the precision of decimal fields (I have not tried it). So, do we want a similar UI to define the tolerance/rounding of float fields? This should probably be discussed in the CCK issue queue... ;)
Comment #8
rweait commentedchanged to CCK issue queue.
Comment #9
karens commentedThis is a limitation of the float field used in D5. See #501016: Big numbers (>10,000) get rounded up and other reports. This won't get fixed in D5. D6 has a proper decimal field.