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
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've gotten every TestQueryParser test to pass without modification
including this new one:
public void testPrecedence() throws Exception {
Query
26 matches
Mail list logo
