Hi John,

thank you very much for looking into this. I can confirm that my test case
problem is now solved. Good work!

Petr

On Sun, Jun 21, 2015 at 10:12 AM, K. John Wu <[email protected]> wrote:

> Hi, Petr,
>
> I have a fix checked in as SVN revision 822.  Would you mind give it a
> try?  Thanks.
>
> John
>
>
> On 6/17/15 5:06 AM, Petr Velan wrote:
> > Hello John,
> >
> > I'd like to revive the thread about this issue. Have you been able to
> > reproduce it? I'd like to offer any further assistance in tracking
> > this down. We are using the FastBit in our tools and this particular
> > issue causes us quite a lot of trouble.
> >
> > Thank you very much for your assistance.
> >
> > Kind regards,
> > Petr
> >
> > On Tue, Jun 2, 2015 at 8:09 AM, Rick Hofstede <[email protected]
> > <mailto:[email protected]>> wrote:
> >
> >     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]
> >     <mailto:[email protected]>>
> >     > Reply-To: FastBit Users <[email protected]
> >     <mailto:[email protected]>>
> >     > To: FastBit Users <[email protected]
> >     <mailto:[email protected]>>
> >     >
> >     > Hi John,
> >     >
> >     > thanks for looking into this.
> >     >
> >     > On Sun, May 10, 2015 at 8:46 AM, K. John Wu <[email protected]
> >     <mailto:[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]>
> >     >>> <mailto:[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>
> >     >>>    <http://www.google.com>')) and (EXISTS(e007id2) and
> >     >>>> (e007id2 LIKE 'www.google.com <http://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>
> >     >>>> <http://www.google.com>')) and (EXISTS(e007id2) and (e007id2
> LIKE
> >     >>>> 'www.google.com <http://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> <http://www.google.com
> >     >>> '))"
> >     >>>> doQuery((EXISTS(e007id2) and (e007id2 LIKE 'www.google.com
> >     <http://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]>
> >     <mailto:[email protected]
> >     <mailto:[email protected]>>
> >     >>>> https://hpcrdm.lbl.gov/cgi-bin/mailman/listinfo/fastbit-users
> >     >>>>
> >     >>>    _______________________________________________
> >     >>>    FastBit-users mailing list
> >     >>>    [email protected] <mailto:
> [email protected]>
> >     <mailto:[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] <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