I am using org.apache.lucene.queryparser.classic.QueryParser to generate my
queries in Lucene 6.4.1 and the class level docs indicate there is a "new"
QueryParser in contrib. I am wondering if the documentation in the class
is accurate and if so, where is this "new" QueryP
On queryparser's documentation says:
"Note that QueryParser is not thread-safe."
it only means that the same instance of QueryParser can't be used by
multiple threads, right? But if each thread has its own QueryParser
instance, then it's OK, right?
BTW, the link http://lu
i m using lucene(org.apache.lucene) and i want the java code for parsing
single character string..
my code is :
QueryParser qp = new QueryParser("",analyser);
String str = " track 9";
Query que = qp.parse(str);
System.out.println(que);
and i want the answer as :
Dear Team,
we are using lucene in our product , it well searching for high
speed and performance but
Japaneese, chinese and korean language not searching properly
we had use QueryParser
QueryParser is splitted into word like "轻歌
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
Hi,
I am currently evaluating the need for an elaborate query
data-structure (to be exchanged over XML-RPC) as opposed to working
with plain strings.
One thing that would heavily vote for strings would be to have query
objects returned by Query-parser reconvertible to a string (and bac
Right, just don't share the same instance across threads.
- Mark
On Oct 18, 2008, at 3:11 PM, "Rafael Almeida" <[EMAIL PROTECTED]>
wrote:
On queryparser's documentation says:
"Note that QueryParser is not thread-safe."
it only means that the same inst
ception and I cannot see why these ones
shouldn't be allowed to.
Another question - is there a recommended way to extend
MultiFieldQueryParser for the same purpose? It looks like it extends
QueryParser and there is no easy way to plug own parser here.
Thanks in adv
Method
static public Query parse(String query, String field, Analyzer analyzer)
in class QueryParser is deprecated in 1.9.1 and the suggestion is: /"Use
an instance of QueryParser and the [EMAIL PROTECTED] #parse(String)} method instead."/
My question is: in the context of multi thread
Hi,
I have a search UI that allows search criteria to be input against specific
fields, e.g. Subject.
In order to create a suitable Lucene Query, I must analyze that String so that
it becomes a set of Tokens which I can then turn into Terms. QueryParser seems
to fit the bill for that
Using QueryParser to parse *tex* seems to create a PrefixQuery rather than
WildcardQuery due to the trailing *, rather than Wildcard because of the other
leading *.
As a result, this does not match, for example "context". I've swapped the order
of WILDTERM and PREFIXTERM in qu
What do you get if you do a
System.out.println(que.toString())?
And what analyzer are you using?
Erick
On 6/28/07, pratik shinghal <[EMAIL PROTECTED]> wrote:
i m using lucene(org.apache.lucene) and i want the java code for parsing
single character string..
my code is :
QueryPar
On Jun 28, 2007, at 1:29 PM, pratik shinghal wrote:
i m using lucene(org.apache.lucene) and i want the java code for
parsing
single character string..
my code is :
QueryParser qp = new QueryParser("",analyser);
String str = " track 9";
Query que = qp.parse(str);
Sy
a code for parsing
> single character string..
>
> my code is :
>
> QueryParser qp = new QueryParser("",analyser);
> String str = " track 9";
> Query que = qp.parse(str);
> System.out.println(que);
>
> and i want the answer as :track , 9
>
t; Erick
>
> On 6/28/07, pratik shinghal <[EMAIL PROTECTED]> wrote:
> >
> > i m using lucene(org.apache.lucene) and i want the java code for
parsing
> > single character string..
> >
> > my code is :
> >
> > QueryParser qp = new QueryParser(
when i m using normal tokenizers i m getting " track " as a result and not
getting " 9 ".
and when i m using this custom analyser and checking the output , i m
getting the right output as " track 9 ".
but as soon as i use queryparser using the same custom analyse
What analyzer are you using? smartcn?
From: kalaik [kalaiselva...@zohocorp.com]
Sent: Friday, March 21, 2014 5:10 AM
To: java-user@lucene.apache.org
Subject: QueryParser
Dear Team,
we are using lucene in our product , it well searching
hinese and korean language not searching properly
we had use QueryParser
QueryParser is splitted into word like "轻歌曼舞庆元旦"
Example
This word "轻歌曼舞庆元旦"
split
igh speed and performance but
>
>
> Japaneese, chinese and korean language not searching properly
> we had use QueryParser
>
>
> QueryParser is splitted into word like "轻歌曼舞庆元旦"
>
>
> Example
>
>
--
Dear Team,
we are using lucene in our product , it well searching for
high speed and performance but
Japaneese, chinese and korean language not searching properly
we had use QueryParser
QueryParser is splitted into word like "轻歌曼舞庆元旦"
To expand on Herb's comment, in Lucene, the StandardAnalyzer will break CJK
into characters:
1 : 轻
2 : 歌
3 : 曼
4 : 舞
5 : 庆
6 : 元
7 : 旦
If you initialize the classic QueryParser with StandardAnalyzer, the parser
will use that Analyzer to break this string into individual characters as
ndardAnalyzer will break
> CJK into characters:
>
> 1 : 轻
> 2 : 歌
> 3 : 曼
> 4 : 舞
> 5 : 庆
> 6 : 元
> 7 : 旦
>
> If you initialize the classic QueryParser with StandardAnalyzer, the
> parser will use that Analyzer to break this string into individual
> charact
hat there was a dicussion on this
issue on the lucene uses list.
I found it and yes, it was explaining that QueryParser is rather
primitive and does not take the usual
operator precedence into account.
Then I read the explanation of types of queries in the "Lucene in
Action" and ever
Hi all,
I built a wrong query string "word1,word2,word3" instead of "word1
word2 word3"
therefore I got a wrong query: field:"word1 word2 word3" instead of
field:word1 field:word2 field:word3.
Is this an espected behaviour?
I used Standard analyzer, probably therefore, the comas were repl
I am wondering if anyone has existing code for a simpler QueryParser -
one that does not create the more complex prefix/fuzzy/range queries,
but still allow the usual term/boolean queries.
I use QueryParser to directly parse user input (allowing for more
flexible specification of include/exclude
Hi there
Who can tell me why I got the the queryParser error for the following query:
Error in parse query :The light of the body is the eye: if therefore thine
eye be single, thy whole body shall be full of light. But if thine eye be
evil, thy whole body shall be full of darkness. If
Hi there
Who can tell me why I got the the queryParser error for the following query:
Error in parse query :The light of the body is the eye: if therefore thine
eye be single, thy whole body shall be full of light. But if thine eye be
evil, thy whole body shall be full of darkness. If
the JavaCC
learning curve so there are quite possibly cases that it does not
handle properly, though it does pass all of the test cases from
QueryParser (with the noted exception).
In my local code, I have deprecated QueryParser and will commit that
once I'm comfortable that this new one is at
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 mak
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 "Old
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 cur
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
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
hough I haven't thought through
exactly how that should be designed. For example, I'm building a very
custom query parser for a client that looks nothing like QueryParser
syntax. It would be very nice to be able to turn a Query back around
into their expression syntax.
I think havin
ween SHOULD BooleanClauses.
I still believe that we need to have some query-parser-specific way to
build strings from Query objects, though I haven't thought through
exactly how that should be designed. For example, I'm building a very
custom query parser for a client that looks no
ough to add - but is that what we want to happen?
> Community, thoughts?
>
Throwing an exception is presumably the other alternative.
Could that check be done in an overwritable method?
> > In an application, I handled this by dropping the query and notifying
> > the
> >
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
Analyzer()));
The output is:
a OR b +c
And the test passes and the query is expressible in QP syntax for
AND unless I'm missing something obvious here.
Silently drop as in you removed them entirely from the resultant
Query?
Right. `a AND (NOT b)' parses to `a'
Is th
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
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 ins
t;
> And the test passes and the query is expressible in QP syntax for
> AND unless I'm missing something obvious here.
>
Ok, you're right, if you mix boolean queries and flags you can do that.
I don't like that because it's hard to explain.
And if you understand
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. Per
then re-generate the
Lucene query as needed. For example, if you wanted to add an "author"
field that was searched by default, then all of the queries in your
database would be invalid. Also, more to the point, if Query.toString()
changes, the semantics of your queries might change,
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
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
ving QP return a BooleanQuery with one clause is perfectly valid and
ideal for me, becuase it let's people say "+author:foo +text" or
"+author:foo -text")
: > Is this what we want to happen for a general purpose next generation
: > Lucene QueryParser though? I'
uctures make sense or not, just to know what
the
sanest possible maping from text to query object tree is.
That is a very reasonable mandate for QueryParser. I agree.
I have committed a round of changes to the PrecedenceQueryParser. I'm
going to leave it alone for a while. There are a couple
ur queries might change, or if the QueryParser changes
they might even become unparsable.
You are right ... The problem is that the generated String is used in
extended search functionality, which is quite often improved. Storing
the "test ko AND NOT bo" string is not enough to rege
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
ry object structures make sense or not, just to know
what the
sanest possible maping from text to query object tree is.
That is a very reasonable mandate for QueryParser. I agree.
I have committed a round of changes to the PrecedenceQueryParser. I'm
going to leave it alone for a whi
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
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
QueryP
On Apr 14, 2005, at 11:32 AM, Paul Libbrecht wrote:
Hi,
I am currently evaluating the need for an elaborate query
data-structure (to be exchanged over XML-RPC) as opposed to working
with plain strings.
One thing that would heavily vote for strings would be to have query
objects returne
Paul Libbrecht wrote:
I am currently evaluating the need for an elaborate query data-structure
(to be exchanged over XML-RPC) as opposed to working with plain strings.
I'd opt for both. For example:
"java based" -coffee
site
apache.org
d
sdx/search/lucene/queryparser/DefaultQueryParser.jj?rev=1.16&content-type=text/vnd.viewcvs-markup
and search for : NO_ANALYSIS
You will see that we need an "UnanalyzedQuery" class which is already
packaged for Lucene ;-)
http://savannah.nongnu.org/cgi-bin/viewcvs/sdx/sdx_v2/src/java/
ging that using the QueryParser.setOperator(1) method. I
put in some logging to confirm that the implicit operator is changing but
the search results still seem to be producing results using ORing the
terms. Here's what the code looks like:
QueryParser qp = new QueryParser( queryField, an
I don't understand, why does the following code create 2 phrase
queries instead of 20 term queries? I'm quite sure I've previously
had QueryParser doing the latter.
System.out.println(new QueryParser("f", new Analyzer() {
public TokenStream tokenStream(Str
This may have been answered before, but is there a reason why setting
the default operator on a QueryParser throws a
java.lang.NoSuchFieldError???
QueryParser parser = new QueryParser( "title", new TokenAnalyzerImpl()
);
parser.setDefaultOperator( QueryParser.AND_OPERATOR ); // This l
Hello,
I am experiencing a strange behaviour when trying to query the same thing
via
BooleanQuery vs. via the know-it-all QueryParser class. Precisely, the index
contains
the document:
"12,Visual C++,4.2" with the field layout: ID,name,version(thus, "12" is
the ID fi
public class AnalyzerTest {
@Test
public void test() throws ParseException {
QueryParser parser = new MultiFieldQueryParser(new String[]{"title",
"body"}, new StandardAnalyzer());
Query query1 = parser.parse("中文");
Qu
On 10/9/06, Stanislav Jordanov <[EMAIL PROTECTED]> wrote:
Method
static public Query parse(String query, String field, Analyzer analyzer)
in class QueryParser is deprecated in 1.9.1 and the suggestion is: /"Use
an instance of QueryParser and the [EMAIL PROTECTED] #parse(String)} meth
static String QueryParser.escape(String) should do the trick:
<http://lucene.apache.org/java/docs/api/org/apache/lucene/queryParser/QueryParser.html#escape(java.lang.String)>
Look at the bottom of the below-linked page for the list of characters
that the above method will escape:
: important:conference agenda
: I want to end up with
:
: +subject:important +subject:conference +subject:agenda
:
: I've written something to do this, but I know it is not as clever as QP as
: currently it can only create BooleanQueries with TermQueries and cannot handle
: PhraseQuery, so would
Keep in mind that this would not work for
important:"conference agenda"
as the quotes would be escaped and queryparser will not generate a phrase query
- Mark
Steven Rowe wrote:
static String QueryParser.escape(String) should do the trick:
<http://lucene.apache.org/java/docs/a
Chris Hostetter wrote:
: important:conference agenda
: I want to end up with
:
: +subject:important +subject:conference +subject:agenda
:
: I've written something to do this, but I know it is not as clever as QP as
: currently it can only create BooleanQueries with TermQueries and cannot handle
Mark Miller wrote:
if you scan the query and escape all colons (ie \:) then you should be
good (I have not verified). Of course you will not be able to do a field
search, but that seems to be what your after.
Thanks for that suggestion. However, a standard un-escaped parse gives
Input - impo
pecific analysers, so having a different query parser for the
named fields and the free form field is fine.
It doesn't seem like you need a "parser" at all for your field-
specific search fields. Simply tokenize, using a Lucene Analyzer,
the text field and build up a BooleanQ
Sorry if I'm missing the point here, but what about simply replacing colons
with spaces first?
Michael.
> -Original Message-
> From: Antony Bowesman [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, November 21, 2006 10:01 PM
> To: java-user@lucene.apache.org
> Subject: Re:
replacing
colons
with spaces first?
Michael.
> -Original Message-
> From: Antony Bowesman [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, November 21, 2006 10:01 PM
> To: java-user@lucene.apache.org
> Subject: Re: Limiting QueryParser
>
> Mark Miller wrote:
> > if you s
Michael Rusch wrote:
Sorry if I'm missing the point here, but what about simply replacing colons
with spaces first?
Michael.
Err, thanks. I've been in too deep at the wrong end :) Wood, trees and
visibility spring to mind!
Antony
--
ogged down with trying to
support PhraseQueries in case of quoted input. My knowledge of JavaCC is
limited, so I was trying to weigh up the effor of rolling my own or adapting QP.
QueryParser is over prescribed - and is often not the best fit for the
job. It's only a few lines of
I have finally delved back into the Lucene Query parser that I started a
few months back. I am very closing to wrapping up it's initial
development. I am currently looking for anybody willing to help me out
with a little testing and maybe some design consultation (I am not happy
with the curren
I have discovered a serious bug in QueryParser. The following query:
contents:sales && contents:marketing || contents:industrial &&
contents:sales
is parsed as:
+contents:sales +contents:marketing +contents:industrial +contents:sales
The same parsed query occurs even
ld be listed next.
3. Results having "all the terms" of the query string in summary should be
listed next
4. Results having "any of the terms" of the query string in the summary
should come last.
How do I construct the query using QueryParser. The fields to be searched
are &quo
he.org
: Subject: QueryParser bug?
:
: Using QueryParser to parse *tex* seems to create a PrefixQuery rather than
: WildcardQuery due to the trailing *, rather than Wildcard because of the other
: leading *.
:
: As a result, this does not match, for example "context". I've swapp
che.org
: To: java-user@lucene.apache.org
: Subject: QueryParser bug?
:
: Using QueryParser to parse *tex* seems to create a PrefixQuery rather than
: WildcardQuery due to the trailing *, rather than Wildcard because of the other
: leading *.
:
: As a result, this does not match, for example "context
: than just on/off), but the original QP shows the problem with
: setAllowLeadingWildcard(true). The compiled JavaCC code will always create a
: PrefixQuery if the last character is *, regardless of any other wildcard
: characters before it. Therefore the query is based on the Term:
Yep, defini
Hi Antony,
Could you try the patch in
http://issues.apache.org/jira/browse/LUCENE-813
Thanks,
Doron
Chris Hostetter <[EMAIL PROTECTED]> wrote on 22/02/2007 22:01:00:
>
> : than just on/off), but the original QP shows the problem with
> : setAllowLeadingWildcard(true). The compiled JavaCC code
Thanks Doron, that works.
Antony
Doron Cohen wrote:
Hi Antony,
Could you try the patch in
http://issues.apache.org/jira/browse/LUCENE-813
Thanks,
Doron
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands,
cards.
Example: *project*
When I insert a ? somewehere in the query, it works again, which leads me to
the conclusion that this must be a bug in the QueryParser.
Example: *pro?ect*
Is this a known issue? I couldn't find anything about this.
Thanks a lot!
Michae
Hi,
I was wondering if a QueryParser can be reused (Lucene ver: 4.6.0)?
>From my experiment it looks like it retains some state from the
previous query.
Isolated example:
public class Test {
public static void main(String[] args) throws ParseException, IOException {
MyAnaly
Hi,
Let's say we have an index having few documents indexed using
StopAnalyzer.ENGLISH_STOP_WORDS_SET. The user issues two queries:
1) foo:bar
2) baz:"there is"
Let's assume that the first query yields some results because there
are documents matching that query.
The second query contains two st
Hello!
I have a small issue with the QueryParser in my program.
It uses my custom filter to Parse its queries, but i get unexpexted
results from when i am having an input from the keyboard
To illustrate
the code :
Analyzer myAnalyzer = new ProperNameAnalyzer();
Query query = new
500 567
2010-04-21 02:24:04 GET /blank 200 897
2010-04-21 02:24:04 POST /blank 200 567
2010-04-21 02:24:05 GET /US/search 200 658
2010-04-21 02:24:05 POST /US/shop 200 768
2010-04-21 02:24:05 GET /blank 200 347
I am querying it in two ways, first with QueryParser and other with
BooleanQuery
ably therefore, the comas were replaced
: with spaces.
the commas weren't replaced ... your analyzer split on them and threw
them away.
they key to understanding why that resulted in a phrase query instead of
three term queries is that QueryParser doesn't treat comma as a special
character
ed Standard analyzer, probably therefore, the comas were replaced
: with spaces.
the commas weren't replaced ... your analyzer split on them and threw
them away.
they key to understanding why that resulted in a phrase query instead of
three term queries is that QueryParser doesn't treat com
: >they key to understanding why that resulted in a phrase query instead of
: >three term queries is that QueryParser doesn't treat comma as a special
: >character, so it saw the string word1,word2,word3 and gave it to your
: >analyzer. Since your analyzer gave back several t
Chris Hostetter wrote:
: Exactly this is my question, why the QueryParser creates a Phrase query
: when he gets several tokens from analyzer
: and not a BooleanQuery?
Because if it did that, there would be no way to write phrase queries :)
I'm not very sure about this ...
QueryP
> From the user's point of view I think it will make sense to
> build a phrase query only when the quotes are found in the search string.
You make an interesting point Sergiu. Your proposal would increase
the expressive power of the QueryParser by allowing the construction
of ei
Yonik Seeley wrote:
From the user's point of view I think it will make sense to
build a phrase query only when the quotes are found in the search string.
You make an interesting point Sergiu. Your proposal would increase
the expressive power of the QueryParser by allowin
I've noticed that while the QueryParser (both the default QueryParser and
the PrecedenceQueryParser) refuse to parse
foo bar) baz
they both seem to interpret
foo bar( baz
as
foo bar
Bug or feature?
In any case, would be great if there was a "strict" mode, and a mor
"Chun Wei Ho" <[EMAIL PROTECTED]> wrote on 20/03/2006 11:09:38 AM:
> I am wondering if anyone has existing code for a simpler QueryParser -
> one that does not create the more complex prefix/fuzzy/range queries,
> but still allow the usual term/boolean queries.
>
>
You need to escape the colons.
miki sun wrote:
Hi there
Who can tell me why I got the the queryParser error for the following
query:
Error in parse query :The light of the body is the eye: if therefore
thine eye be single, thy whole body shall be full of light. But if
thine eye be evil
is that darkness!
java.lang.NullPointerException
Original Message Follows
From: Michael Barry <[EMAIL PROTECTED]>
Reply-To: java-user@lucene.apache.org
To: java-user@lucene.apache.org
Subject: Re: QueryParser error
Date: Tue, 04 Apr 2006 06:44:02 -0400
You need to escape the
Exclamation point too ... check out the "Escaping Special Characters"
section in the QueryParser syntax guide
(http://lucene.apache.org/java/docs/queryparsersyntax.html)
miki sun wrote:
Still got error even without colon:
Error in parse query :The light of the body is the eye if
Miki hasn't posted a complete stack trace, and if the NPE is coming
from QueryParser it would likely give stack trace information
pinpointing precisely where the issue is. My hunch is some other
code is obfuscating the real issue. A complete stack trace would be
much more he
Hi all,
I´m using lucene 2.0.0 and I would like to generate a BooleanQuery from a
QueryParser. The problem is that when I parse a query like this: "(rafael
todor rossini)~2" the property of the BooleanQuery ,
minimumNumberShouldMatch is not setted properly. Is there a way of doing
tha
Dear reader,
I'm trying to test lucene 8.2.0 as key-value store;
I know that there are specialized ones like lmdb etc...
As key I have a StringField, keys can contain space(s), e. g. "a b". I
know I should use TermQuery.
But I've been playing with classic QueryParser,
The documentation tells us to escape special characters by using the \
Example:
\(1\+1\)
However if we put this in a string
String query = "\(1\+1\)";
Then the java compiler throws an Invalid Escape Sequence error.
QueryParser doesn't seem to recognize the double backsla
Hi,
We have implemented a lucene search like this:
registry = LocateRegistry.getRegistry(RMIAddress, RMIPort);
searchables = new Searchable[] { (Searchable) registry.lookup(RMIIndexName)};
queryParser = new QueryParser(defaultField, new StandardAnalyzer());
Query query = queryParser.parse
1 - 100 of 524 matches
Mail list logo
