Hi, Petr, Please add letter 'L' to the end of the long integer in the where clause.
There are two expressions that can take a long integer: on the right-hand side of a equality operator and inside parentheses on the right of the operator "IN". With the letter 'L', a long integer is treated as a floating-point number. In your particular case, because the floating-point number does not have enough precision to keep all the digits, thus it can not be successfully compared against the integer version of itself. Hope this helps. John On 7/20/15 8:51 PM, Petr Velan wrote: > Hi John, > > I've encountered a problem with filtering 64bit integers. I'm not sure > whether this is related to other data types as well. The issue is that > the query does not return expected value. I have a data set containing > value 2306131613952251473 which is present according to this query: > > $ thula -d . -s " e0id27p0" -w "1 = 1" -v 1 2>&1 | grep > 2306131613952251473 > 2306131613952251473, 2306131613952251473, 2306131613952251473, > 5.35460699443745e+22, 2.30613161395299e+18, 1.3151790654792e+24, > 1.31523571028346e+24, 1146812567719.41, 1146837264080.42, 1 > > However, when I ask for the specific row, I do not get any result: > $ thula -d . -s " e0id27p0" -w "e0id27p0 = 2306131613952251473" > doQuery(e0id27p0 = 2306131613952251473) evaluated on T-257 produced 0 > hit out of 30646 records > -- begin printing the result table -- > Table UVlcT2 (filter::sift1) contains 0 row and no column > -- end printing -- > > I've attached the data set so that you can reproduce the issue. Please > let me know if you need more information or help with reproducing the > issue. > > Thanks, > Petr > > > _______________________________________________ > 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
