Unfortunately, there is no ease way to get arround this problem with the current software. It will take a redesign to get rid off this limitation. John
On 5/27/10, Stuart Castergine <[email protected]> wrote: > I have an index that includes values indexed (via ardea) as long. > > when querying using ibis for very large values, it looks like ibis is > interpreting the long integers in the query string as double precision, > causing them to faiil for exact integer matches. Here's an example: > > Note that the session_id 5146415197860370806 is confirmed to exist in the > data and is visible if you do range-based queries (such as session_id > 0). > > /opt/narus/fdm/default/software/site/bin/ibis -d test -q "select session_id > where session_id == 5146415197860370806" > doQuery:: evaluate(SELECT session_id FROM test WHERE session_id == > 5146415197860370806) produced 0 hit, took 0 CPU seconds, 0.146936 elapsed > seconds > If you run the query with verbosity 2 (-v=2), you see this: > > part::doScan -- evaluating session_id == 5.14642e+18 on 10 m values (total: > 1725 > 96) took 4.98295e-05 sec elapsed time and produced 0 hit > Which leads me to believe that the value is being converted to a > double-precision and is therefore unable to match the exact long integer. > > Is there a way in the query syntax to force ibis to treat the value as a > long? > > Thanks, > > Stuart Castergine > [email protected]<mailto:[email protected]> > M: 614-264-7986 > O: 740-347-9300 > _______________________________________________ > FastBit-users mailing list > [email protected] > https://hpcrdm.lbl.gov/cgi-bin/mailman/listinfo/fastbit-users > _______________________________________________ FastBit-users mailing list [email protected] https://hpcrdm.lbl.gov/cgi-bin/mailman/listinfo/fastbit-users
