On Mar 9, 2005, at 7:40 AM, sergiu gordea wrote:
Unfortunately I don't have a lucene project on my computer as this
moment and I cannot check myself,
do the tests for MultiFieldQueryParser also pass?
I haven't tried it, though I'm sure it'd be fine since it relies on
QueryParser. Since I have no
On Mar 9, 2005, at 7:25 AM, sergiu gordea wrote:
transformations to be reversible
(I mean something like Query => String => Query, with the constraint
initial query equals final query).
Ok ... I give up ... if this feature is to hard to be implemented,
the soltution will be to work around in my
Erik Hatcher wrote:
On Mar 8, 2005, at 5:17 PM, Chris Hostetter wrote:
Earlier in this thread...
: >>> +a -> a
: >>
: >> Hmmm this is a debatable one. It's returning a TermQuery in
this
: >> case for "a". Is that appropriate? Or should it return a
: >> BooleanQuery
: >> with a single TermQu
Chris Hostetter wrote:
Earlier in this thread...
: >>> +a -> a
: >>
: >> Hmmm this is a debatable one. It's returning a TermQuery in this
: >> case for "a". Is that appropriate? Or should it return a
: >> BooleanQuery
: >> with a single TermQuery as required?
: > Ok.
: > The question how to
Doug Cutting wrote:
sergiu gordea wrote:
So .. here is an example of how I parse a simple query string
provided by a user ...
the user checks a few flags and writes "test ko AND NOT bo"
and the resulting query.toString() is saved in the database:
+(+(subject:test description:test keywordsTerms:te
On Mar 8, 2005, at 5:17 PM, Chris Hostetter wrote:
Earlier in this thread...
: >>> +a -> a
: >>
: >> Hmmm this is a debatable one. It's returning a TermQuery in
this
: >> case for "a". Is that appropriate? Or should it return a
: >> BooleanQuery
: >> with a single TermQuery as required?
:
Earlier in this thread...
: >>> +a -> a
: >>
: >> Hmmm this is a debatable one. It's returning a TermQuery in this
: >> case for "a". Is that appropriate? Or should it return a
: >> BooleanQuery
: >> with a single TermQuery as required?
: > Ok.
: > The question how to handle BooleanQuerie
On Mar 8, 2005, at 12:38 PM, Morus Walter wrote:
That reminds me of a remark Doug made in the discussion of bug
25820 (http://issues.apache.org/bugzilla/show_bug.cgi?id=25820#c7),
that it would be useful if an empty query string parses to an empty
query. So probably a check for that should be added
Erik Hatcher writes:
> >> I think you must have tried this in a transient state when I forgot
> >> to
> >> check in some JavaCC generated files. Try again. This one now
> >> returns
> >> an empty BooleanQuery.
> >>
> > ok.
> > I'm a bit puzzled, since I called javacc myself, so generated files
sergiu gordea wrote:
So .. here is an example of how I parse a simple query string provided
by a user ...
the user checks a few flags and writes "test ko AND NOT bo"
and the resulting query.toString() is saved in the database:
+(+(subject:test description:test keywordsTerms:test koProperties:test
Daniel Naber writes:
> On Tuesday 08 March 2005 14:46, Erik Hatcher wrote:
>
> > > Right. `a AND (NOT b)' parses to `a'
> >
> > Is this what we want to happen for a general purpose next generation
> > Lucene QueryParser though? I'm not sure. Perhaps this should be a
> > ParseException instead?
Erik Hatcher writes:
>
> On Mar 8, 2005, at 4:38 AM, Morus Walter wrote:
> >> I created a modified Query->String converter for my current day time
> >> project (as I use a String representation for the most recently used
> >> drop-down that is stored as a client-side cookie) that explicitly puts
>
On Tuesday 08 March 2005 14:46, Erik Hatcher wrote:
> > Right. `a AND (NOT b)' parses to `a'
>
> Is this what we want to happen for a general purpose next generation
> Lucene QueryParser though? I'm not sure. Perhaps this should be a
> ParseException instead?
As we have no concept of a "warnin
Erik Hatcher wrote:
On Mar 8, 2005, at 4:11 AM, sergiu gordea wrote:
In our project I save search strings, generated with query.toString
in the database and I reconstruct the Query at runtime.
I would appreciate if the new QueryParser will pass the following
assert:
Query query = QueryParser.pa
On Mar 8, 2005, at 4:38 AM, Morus Walter wrote:
I created a modified Query->String converter for my current day time
project (as I use a String representation for the most recently used
drop-down that is stored as a client-side cookie) that explicitly puts
in "OR" between SHOULD BooleanClauses.
You
On Mar 8, 2005, at 4:11 AM, sergiu gordea wrote:
In our project I save search strings, generated with query.toString in
the database and I reconstruct the Query at runtime.
I would appreciate if the new QueryParser will pass the following
assert:
Query query = QueryParser.parse(queryString, ana
Erik Hatcher writes:
> > ok.
> > I'm a bit puzzled, since I called javacc myself, so generated files
> > should
> > not matter, but if it's fixed, I don't care about what went wrong.
>
> Let me know if there is still an issue, though I added this exact case
> to TestPrecedenceQueryParser and its
2) Single term queries using +/- flags are parse to a query without
flag
+a -> a
Hmmm this is a debatable one. It's returning a TermQuery in this
case for "a". Is that appropriate? Or should it return a BooleanQuery
with a single TermQuery as required?
I'd prefer, if query parser parses qu
On Mar 8, 2005, at 2:29 AM, Morus Walter wrote:
Erik Hatcher writes:
Your changes look great in general, though I find some issues:
1) 'stop OR stop AND stop' where stop is a stopword gives a parse
error:
Encountered "" at line 1, column 0.
Was expecting one of:
...
...
I think you must have
Erik Hatcher writes:
> > Your changes look great in general, though I find some issues:
> >
> > 1) 'stop OR stop AND stop' where stop is a stopword gives a parse
> > error:
> > Encountered "" at line 1, column 0.
> > Was expecting one of:
> > ...
> > ...
>
> I think you must have tried this
Morus - thanks for your quick checks. More below
On Mar 7, 2005, at 3:32 PM, Morus Walter wrote:
I had a quick look at the new QP. I didn't look at the code yet, but I
redid my patch at the weekend for the current code, and I found it
quite
ugly ;-) I didn't finish it completely, so I didn't
Hi Erik,
> I've been making local changes to QueryParser to fix the operator
> precedence issues (i.e. currently A AND B OR C AND D parses to +A +B +C
> +D).
>
I had a quick look at the new QP. I didn't look at the code yet, but I
redid my patch at the weekend for the current code, and I found
On Mar 7, 2005, at 11:35 AM, Daniel Naber wrote:
On Monday 07 March 2005 11:30, Erik Hatcher wrote:
- Deprecate our current QueryParser and refer users to the new
PrecedenceQueryParser.
I'd consider fixing the precedence a bugfix, so I' prefer to rename
QueryParser to "OldQueryParser" or so
On Monday 07 March 2005 11:30, Erik Hatcher wrote:
> - Deprecate our current QueryParser and refer users to the new
> PrecedenceQueryParser.
I'd consider fixing the precedence a bugfix, so I' prefer to rename
QueryParser to "OldQueryParser" or so and make the new one "QueryParser".
Rega
I've gone ahead and committed my PrecedenceQueryParser. I cloned
TestQueryParser into TestPrecedenceQueryParser and fixed the one item
mentioned below.
Please give this new PrecedenceQueryParser a try and report back any
issues you find with it. I'm still on the steep side of the JavaCC
lear
25 matches
Mail list logo
