Fixes bug 497 - Filtering date dimensions for row/pie

[mtraynham]

Fixes Bug #497.

Correctly coerce dates to primitives for comparison.

[mtraynham]

Added some changes to removeFilter and hasFilter. Dates are objects and indexOf relies on the fact that they are the same objects in memory, but it really needs to be a coercive comparison.

[gordonwoodhull]

Hi @mtraynham, I am finally merging this. Thanks!

I figured you probably wouldn't mind me snagging parts of your fiddle for the jasmine spec. If you have a minute, could you double check the test in 9c682c9? It definitely fails before your patch and succeeds after, but it fails differently from your fiddle: whereas your fiddle usually shows little stubs of wrong values, this just gets a straight zero wrong value.

[mtraynham]

Interesting. I have to fix that fiddle and try it out.

The stubs left over should be correct. When you filter, you take the rows dimensional value. Since this corresponds to one of the dates in crossfilter index, it should match at most the one date reference. The other dates (that are same the date) would be the ones that failed to filter.

[mtraynham]

So broken version:
http://jsfiddle.net/SjT8E/4/

Fixed version:
http://jsfiddle.net/SjT8E/2/

Seems like the number's match up properly when you filter on Charts 3 & 5 now. In the broken version, when you filter, the stub left over should be a subset of what should actually be returned.

[gordonwoodhull]

I linked to updated fiddles in the test. Maybe the difference is that I am filtering directly on a new Date in the test rather than a value from the dataset? Anyway, thanks very much for the test - it makes me uncomfortable to fix a bug without having a test to verify that it stays fixed.

[mtraynham]

Ahh yes, didn't think to check how you were filtering. You are correct, because the new Date is not actually a value in the crossfilter index, there would be no reference match at all and thus everything is filtered.

[gordonwoodhull]

Ah, and now I get it - it was previously comparing the object references for equality, and JavaScript's == for object references tests identity not value.

So:

> new Date(2014,6,7)==new Date(2014,6,7)
false

I guess the reason for using two comparisons instead of .valueOf() is that .valueOf() would cause primitives to get "boxed" in temporary objects, which is slower than the extra comparison.

[mtraynham]

Correctamundo! Thanks again for accepting the pull request :)