Hi John,

Is there any news on this issue?

Best regards,

—
Rick Hofstede

> -------- Forwarded Message --------
> Subject: Re: [FastBit-users] Where filter on missing columns
> Date: Sun, 10 May 2015 21:02:19 +0200
> From: Petr Velan <[email protected]>
> Reply-To: FastBit Users <[email protected]>
> To: FastBit Users <[email protected]>
> 
> Hi John,
> 
> thanks for looking into this.
> 
> On Sun, May 10, 2015 at 8:46 AM, K. John Wu <[email protected]> wrote:
> 
>> Hi, Petr,
>> 
>> Given that e007id2 does not exist in the data table, the proper answer
>> from the function EXISTS should be "NO".
>> 
>> I agree.
> 
> 
>> Looks like in the case with more where clauses, the reordering
>> function somehow got tangled up and propagated the failure of unable
>> to find a column named e007id2 up through the call chain.  I
>> understand that SQL standard is very tolerant about the error
>> incorrect column names and returns empty answer set is such cases.  Is
>> this your expected behavior as well?
>> 
>> Yes it is. Actually, we use the form (EXISTS col and col = val) in most of
> our queries to ensure that the value exists before it is compared.
> Therefore, the EXISTS should just return 'no' on missing column and the
> query should carry on. By the way, it was working fine in earlier versions,
> but I do not have exact svn revision numbers.
> 
> Petr
> 
>> 
>> On 5/8/15 10:20 PM, Petr Velan wrote:
>>> Hi John,
>>> 
>>> the point is exactly in using e007id2, which is missing in the data
>>> set. We are working with the use case where EXISTS clause comes to
>>> play. When the column is missing in the data set (just like when
>>> e007id2 in this case), we need consistent behavior, preferably a
>>> result with zero rows.
>>> 
>>> Best regards,
>>> Petr
>>> 
>>> On Sat, May 9, 2015 at 3:30 AM, K. John Wu <[email protected]
>>> <mailto:[email protected]>> wrote:
>>> 
>>>    Hi, Petr,
>>> 
>>>    I have tried to run your queries on the data you shared with us some
>>>    time ago in 259.tgz.  In this case, I change e007id2 to e007id1.  In
>>>    this case, I am getting the same results from the two queries.  Would
>>>    you mind share a sample data set with us?
>>> 
>>>    Thanks.
>>> 
>>>    John
>>> 
>>>    On 5/7/15 4:53 AM, Petr Velan wrote:
>>>> Hi John,
>>>> 
>>>> I've run into a problem with where filter on the latest libfastbit
>>>> version. The following queries should return the same result.
>> However,
>>>> the first one fails and the second one returns an empty table,
>> which
>>>> is the expected behavior.
>>>> 
>>>> thula -d . -s " e0id1" -w "(EXISTS(e007id2) and (e007id2 LIKE
>>>> 'www.google.com <http://www.google.com>
>>>    <http://www.google.com>')) and (EXISTS(e007id2) and
>>>> (e007id2 LIKE 'www.google.com <http://www.google.com>
>>>    <http://www.google.com>'))"
>>>> doQuery((EXISTS(e007id2) and (e007id2 LIKE 'www.google.com <
>> http://www.google.com>
>>>> <http://www.google.com>')) and (EXISTS(e007id2) and (e007id2 LIKE
>>>> 'www.google.com <http://www.google.com>
>>>    <http://www.google.com>'))) failed to produce any result
>>>> 
>>>> thula -d . -s " e0id1" -w "(EXISTS(e007id2) and (e007id2 LIKE
>>>> 'www.google.com <http://www.google.com> <http://www.google.com
>>> '))"
>>>> doQuery((EXISTS(e007id2) and (e007id2 LIKE 'www.google.com <
>> http://www.google.com>
>>>> <http://www.google.com>'))) evaluated on T-259 produced 0 hit
>>>    out of 4
>>>> records
>>>> -- begin printing the result table --
>>>> Table UVlcU (filter::sift2) contains 0 row and no column
>>>> -- end printing --
>>>> 
>>>> This issue can be reproduced with the data set provided for the
>>>> previous issue "Failed aggregation query" (sent on 27.4.2015).
>>>> 
>>>> I've managed to produce this issue even by reordering some terms
>>>> around an "and" in the filter. Could you take a look at this?
>>>> 
>>>> Thank you very much in advance,
>>>> Petr
>>>> 
>>>> 
>>>> _____________________________________________
>>>> FastBit-users mailing list
>>>> [email protected] <mailto:[email protected]>
>>>> https://hpcrdm.lbl.gov/cgi-bin/mailman/listinfo/fastbit-users
>>>> 
>>>    _______________________________________________
>>>    FastBit-users mailing list
>>>    [email protected] <mailto:[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
>>> 
>> _______________________________________________
>> 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

Reply via email to