RE: QueryParser with CustomAnalyzer wrongly uses PatternReplaceCharFilter

Hi, this is a general problem of using Analyzers in combination with QueryParser. Query Parsing is done *before* the terms are tokenized: QueryParser uses a JavaCC grammar to parse the query. This involves some query-parsing specific tokenization. Once the query parser has analyzed the syntax,

Re: QueryParser with CustomAnalyzer wrongly uses PatternReplaceCharFilter

Classic QueryParser splits on whitespace and then sends the chunks to the analyzer one at a time. See . -- Steve www.lucidworks.com > On Apr 28, 2016, at 5:54 AM, Bahaa Eldesouky wrote: > > I am using org.apache.lucene.queryparser.classic.Qu

Re: QueryParser

igram > behavior, consider removing that filter; or if you want both bigrams and > unigrams, consider adding: outputUnigrams="true" as in: > > > > > -Original Message- > From: Herb Roitblat [mailto:herb.roitb...@orcatec.com] > Sent: Monday, March 24, 201

RE: QueryParser

you want both bigrams and unigrams, consider adding: outputUnigrams="true" as in: -Original Message- From: Herb Roitblat [mailto:herb.roitb...@orcatec.com] Sent: Monday, March 24, 2014 9:01 AM To: java-user@lucene.apache.org; kalaiselva...@zohocorp.com Subject: Re: QueryParse

Re: QueryParser

The default query parser for CJK languages breaks text into bigrams. A word consisting of characters ABCDE is broken into tokens AB, BC, CD, DE, or "轻歌曼舞庆元旦" into data:轻歌 data:歌曼 data:曼舞 data:舞庆 data:庆元 data:元旦 Each pair may or may not be a word, but if you use the same parser (i.e. analyz

Re: QueryParser

Hi, There was a response to your question (by Timothy Allison) but maybe you didn't see it? Are you subscribed to the mailing list (java-user@lucene.apache.org)? Mike McCandless http://blog.mikemccandless.com On Mon, Mar 24, 2014 at 2:21 AM, kalaik wrote: > Dear Team, > > Any

Re: QueryParser

Dear Team, Any Update ? On Fri, 21 Mar 2014 14:40:51 +0530 kalaik wrote Dear Team, we are using lucene in our product , it well searching for high speed and performance but Japaneese, chinese

RE: QueryParser

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 fo

RE: QueryParser stripping off Hyphen from query

Ian - Thank you for your inputs. Regards, Raghu -Original Message- From: Ian Lea [mailto:ian@gmail.com] Sent: Tuesday, October 15, 2013 11:43 AM To: java-user@lucene.apache.org Subject: Re: QueryParser stripping off Hyphen from query If you want to keep hyphens you could try

Re: QueryParser stripping off Hyphen from query

rdAnalyzer. > > Regards, > Raghu > > > -Original Message- > From: Uwe Schindler [mailto:u...@thetaphi.de] > Sent: Monday, October 14, 2013 6:38 PM > To: java-user@lucene.apache.org > Subject: RE: QueryParser stripping off Hyphen from query > > The problem is not

RE: QueryParser stripping off Hyphen from query

-user@lucene.apache.org Subject: RE: QueryParser stripping off Hyphen from query The problem is not query parser, it is your analyzer. - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de > -Original Message- > From: raghavendra.k@b

RE: QueryParser stripping off Hyphen from query

The problem is not query parser, it is your analyzer. - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de > -Original Message- > From: raghavendra.k@barclays.com > [mailto:raghavendra.k@barclays.com] > Sent: Tuesday, October 15,

RE: QueryParser for DisjunctionMaxQuery, et al.

Oh, sorry! Jim Beale hibu.com 2201 Renaissance Boulevard, King of Prussia, PA, 19406 Office: 610-879-3864 Mobile: 610-220-3067 -Original Message- From: Chris Hostetter [mailto:hossman_luc...@fucit.org] Sent: Tuesday, July 23, 2013 1:42 PM To: java-user@lucene.apache.org Subject: Re

RE: QueryParser for DisjunctionMaxQuery, et al.

ssage- From: Jack Krupansky [mailto:j...@basetechnology.com] Sent: Tuesday, July 23, 2013 10:22 AM To: java-user@lucene.apache.org Subject: Re: QueryParser for DisjunctionMaxQuery, et al. I came up with some human-readable BNF rules for the Solr, dismax, and edismax query parsers. They are in my boo

Re: QueryParser for DisjunctionMaxQuery, et al.

: Subject: QueryParser for DisjunctionMaxQuery, et al. : References: <1374578398714-4079673.p...@n3.nabble.com> : In-Reply-To: <1374578398714-4079673.p...@n3.nabble.com> https://people.apache.org/~hossman/#threadhijack Thread Hijacking on Mailing Lists When starting a new discussion on a mailing

Re: QueryParser for DisjunctionMaxQuery, et al.

I came up with some human-readable BNF rules for the Solr, dismax, and edismax query parsers. They are in my book. In fact they are linked from the "Solr Hot Spots" section in the preface. The main problems with re-parsing from a lucene Query structure are two-fold: 1. Terms have been analyz

Re: QueryParser and BooleanQuery

Hi Trejkaz, I am using the Standard Analyzer for my indexing. Can you provide an example with which I can use the BooleanQuery to add both the fields in the same forms and yet the documents are searched? I would be really grateful if you can provide example for parsing the text as well which is p

Re: QueryParser and BooleanQuery

On Mon, Jul 23, 2012 at 10:16 PM, Deepak Shakya wrote: > Hey Jack, > > Can you let me know how should I do that? I am using the Lucene 3.6 version > and I dont see any parse() method for StandardAnalyzer. In your case, presumably at indexing time you should be using a PerFieldAnalyzerWrapper with

Re: QueryParser and BooleanQuery

ssage- From: Deepak Shakya >> Sent: Sunday, July 22, 2012 9:35 PM >> To: java-user@lucene.apache.org >> Subject: Re: QueryParser and BooleanQuery >> >> >> I tried changing the case to lower case, but still the BooleanQuery doesn't >> return any documents. >

Re: QueryParser and BooleanQuery

Sunday, July 22, 2012 9:35 PM > To: java-user@lucene.apache.org > Subject: Re: QueryParser and BooleanQuery > > > I tried changing the case to lower case, but still the BooleanQuery doesn't > return any documents. > > I see that the text "/blank" is converte

Re: QueryParser and BooleanQuery

-Original Message- From: Deepak Shakya Sent: Sunday, July 22, 2012 9:35 PM To: java-user@lucene.apache.org Subject: Re: QueryParser and BooleanQuery I tried changing the case to lower case, but still the BooleanQuery doesn't return any documents. I see that the text "

Re: QueryParser and BooleanQuery

I tried changing the case to lower case, but still the BooleanQuery doesn't return any documents. I see that the text "/blank" is converted to "blank" in the QueryParser. But in BooleanQuery it remains the same. When I remove the forward slash sign from the input string, I get the matched document

Re: QueryParser and BooleanQuery

The query parser/analyzer is lower-casing the query terms automatically. You have to do the same with with terms for BooleanQuery - Term("cs-method", "GET") should be "Term("cs-method", "get")". StandardAnalyzer is doing the lower-casing. -- Jack Krupansky -Original Message- From: De

Re: QueryParser, double quotes and wilcard inside the double quotes

s/weird/word/ Sorry, autocorrect. On Jul 5, 2012 4:01 PM, "Israel Tsadok" wrote: > A hacky trick I used was put a stop weird instead of the asterisk. If you > search for "foo a test" and use an analyzer that includes a stop filter > (like StandardAnalyzer does), it will match docs 1 and 2. > > On

Re: QueryParser, double quotes and wilcard inside the double quotes

A hacky trick I used was put a stop weird instead of the asterisk. If you search for "foo a test" and use an analyzer that includes a stop filter (like StandardAnalyzer does), it will match docs 1 and 2. On Jul 4, 2012 10:13 AM, "Jochen Hebbrecht" wrote: > > Thanks Ian, I'll give it a try! > > 20

Re: QueryParser, double quotes and wilcard inside the double quotes

Thanks Ian, I'll give it a try! 2012/7/3 Ian Lea > You can use the QueryParser proximity feature e.g. "foo test"~n where > n is the max distance you want them to be apart. Or look at the > SpanQuery stuff e.g. SpanNearQuery. > > > -- > Ian. > > > On Tue, Jul 3, 2012 at 4:59 PM, Jochen Hebbrecht

Re: QueryParser, double quotes and wilcard inside the double quotes

You can use the QueryParser proximity feature e.g. "foo test"~n where n is the max distance you want them to be apart. Or look at the SpanQuery stuff e.g. SpanNearQuery. -- Ian. On Tue, Jul 3, 2012 at 4:59 PM, Jochen Hebbrecht wrote: > Hi all, > > Imagine you have the following books which ar

Re: QueryParser strange behavior

It is fixed now. I need to enable qp.setAutoGeneratePhraseQueries(true); Regards Ganesh - Original Message - From: "Ganesh" To: Sent: Friday, March 02, 2012 10:46 AM Subject: Re: QueryParser strange behavior Hello Damerian, Please let me know, How you fixed the pro

Re: QueryParser strange behavior

her of the token matches, it returns the results. Regards Ganesh - Original Message - From: "Damerian" To: Sent: Thursday, March 01, 2012 7:57 PM Subject: Re: QueryParser strange behavior > Στις 1/3/2012 3:08 μμ, ο/η Ian Lea έγραψε: >> Not a clue. I suggest you po

Re: QueryParser strange behavior

Στις 1/3/2012 3:08 μμ, ο/η Ian Lea έγραψε: Not a clue. I suggest you post a small, complete and self-contained (no external dependencies) program or test case that demonstrates the problem. And your analyzer. -- Ian. 2012/3/1 Damerian: Hello again! First of all thank you again for replying

Re: QueryParser strange behavior

Not a clue. I suggest you post a small, complete and self-contained (no external dependencies) program or test case that demonstrates the problem. And your analyzer. -- Ian. 2012/3/1 Damerian : > Hello again! > First of all thank you again for replying my amateur questions. > I would like to

Re: QueryParser strange behavior

Hello again! First of all thank you again for replying my amateur questions. I would like to rephrase my question because now what i described is not the case and its not a problem of input methods. I have made my custom analyzer which when indexing e.g the phrase "The quick Brown Fox" will p

Re: QueryParser strange behavior

Then I don't know. Something trivial like white space? What does line.equals("Jesus Christ") say? -- Ian. On Mon, Feb 27, 2012 at 7:42 PM, Damerian wrote: > Στις 27/2/2012 11:45 πμ, ο/η Ian Lea έγραψε: >> >> Does your analyzer look for a field called content, not contents? >> >> >> -- >> Ian

Re: QueryParser strange behavior

Στις 27/2/2012 11:45 πμ, ο/η Ian Lea έγραψε: Does your analyzer look for a field called content, not contents? -- Ian. On Sat, Feb 25, 2012 at 6:37 AM, Damerian wrote: Hello! I have a small issue with the QueryParser in my program. It uses my custom filter to Parse its queries, but i get u

Re: QueryParser strange behavior

Does your analyzer look for a field called content, not contents? -- Ian. On Sat, Feb 25, 2012 at 6:37 AM, Damerian wrote: > 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

Re: QueryParser/StopAnalyzer question

Sorry, I was at Lucene Revolution, and out of circulation for a while. I agree with your point that "it depends" (what correct behavior is). Seems like a lot of Solr/Lucene has that answer... But as to stop words, the trend lately is to NOT remove them anyway. The whole stop word issue comes from

Re: QueryParser/StopAnalyzer question

Hi Erick, I think answer to this question depends which hat you put on. If you put search engine hat (or do similar things in, i.e. Google), the results will be the same as what Lucene does at the moment. And that's fair enough - getting more results in search engine world is almost always better

Re: QueryParser/StopAnalyzer question

Hmmm, somehow I missed this days ago Anyway, the Lucene query parsing process isn't quite Boolean logic. I encourage you to think in terms of "required", "optional", and "prohibited". Both queries are equivalent, to see this try attaching &debugQuery=on to your URL and look at the "parsed que

Re: QueryParser/StopAnalyzer question

Not much luck so far :( Just in case if anyone wants to earn some virtual dosh, I have added some 50 bonus points to this question on StackOverflow: http://stackoverflow.com/questions/6044061/lucene-query-parsing-behaviour-joining-query-parts-with-and I also promise to post a solution here if an

Re: QueryParser in 3.x

ts code duplication. simon > > Scott > > > -Original Message- > From: Simon Willnauer [mailto:simon.willna...@googlemail.com] > Sent: Friday, September 17, 2010 1:03 AM > To: java-user@lucene.apache.org > Subject: Re: QueryParser in 3.x > > On Fri, Sep 17, 2010 at 1:06 A

RE: QueryParser in 3.x

mail.com] Sent: Friday, September 17, 2010 1:03 AM To: java-user@lucene.apache.org Subject: Re: QueryParser in 3.x On Fri, Sep 17, 2010 at 1:06 AM, Scott Smith wrote: > I recently upgraded to Lucene 3.0 and am seeing some new behavior that I > don't understand.  Perhaps someone can e

Re: QueryParser in 3.x

On Fri, Sep 17, 2010 at 1:06 AM, Scott Smith wrote: > I recently upgraded to Lucene 3.0 and am seeing some new behavior that I > don't understand.  Perhaps someone can explain why. > > > > I have a custom analyzer.  Part of the analyzer uses the AsciiFoldingFilter.   > If I run a word with an uml

Re: QueryParser returning TermQuery instead of PhraseQuery?

Sorry about that. The areas were related to Lucene specific features in terms of the indexing and parsing. The problem lied with the dataset tied to the entities. I'll be sure to state that before hand in the future. Thanks. Erick Erickson wrote: > > u, that would have been a really usefu

Re: QueryParser returning TermQuery instead of PhraseQuery?

u, that would have been a really useful bit of information in your original post Erick On Tue, Oct 21, 2008 at 4:24 PM, samd <[EMAIL PROTECTED]> wrote: > > I'm using Hibernate Search and now looking I think it is more related to > this. Hibernate Search indexing and parsing is based on L

Re: QueryParser returning TermQuery instead of PhraseQuery?

I'm using Hibernate Search and now looking I think it is more related to this. Hibernate Search indexing and parsing is based on Lucene but it is tied to the entities unless you use projections. I guess I'll need to go down this road for now. Thanks -- View this message in context: http://www.

Re: QueryParser returning TermQuery instead of PhraseQuery?

this can absolutely be done, so don't go off the deep end . Could we see the index snippet and the search snippet when you tried with StandardAnalyzer? Etick On Tue, Oct 21, 2008 at 2:59 PM, samd <[EMAIL PROTECTED]> wrote: > > I have tried doing both the indexing and parsing with the same parse

Re: QueryParser returning TermQuery instead of PhraseQuery?

I have tried doing both the indexing and parsing with the same parser being the StandardAnalyzer. I'm seeing the same result. I'm going to have to search based off the documentid by the looks of it if I can't do an exact search on a single term. Erick Erickson wrote: > > I'd really recommend

Re: QueryParser returning TermQuery instead of PhraseQuery?

I'd really recommend you get a copy of Luke and examine what your index really contains. You say: <<>> StandardAnalyzer? When? If you *index* with SnowballAnalyzer, your token would (probably) be "foo" rather than "foo1". So at *query* time, it wouldn't make any difference whether you used Standa

Re: QueryParser returning TermQuery instead of PhraseQuery?

The Snowball Analyzer was chosen since there are cases where the stemming is desired. This is one case where it is not although the same results are produced with the Standard Analyzer. If this doesn't work I guess I'll probably need to try to programmatically provide an additional field to the se

Re: QueryParser returning TermQuery instead of PhraseQuery?

samd wrote: I have field for example say "foo" I need to match exactly foo but there is also another field for exampled called "foo1" What I want is a PhraseQuery so I surround foo with quotes before it gets passed to the QueryParser.parse method. However I get back a TermQuery and the values th

Re: QueryParser

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 instance of QueryParser can't be used by mu

Re: QueryParser vs. BooleanQuery

Indeed, StandardAnalyzer removing the pluses, so analyse 'c++' to 'c'. QueryParser include Term that been analysed. And BooleanQuery include Term that hasn't been analysed. I think this is the difference between they. 2008/9/4 Ian Lea <[EMAIL PROTECTED]> > Have a look at the index with Luke to

Re: QueryParser vs. BooleanQuery

Have a look at the index with Luke to see what has actually been indexed. StandardAnalyzer may well be removing the pluses, or you may need to escape them. And watch out for case - Visual != visual in term query land. -- Ian. On Thu, Sep 4, 2008 at 9:46 AM, bogdan71 <[EMAIL PROTECTED]> wrote:

RE: QueryParser Default Operator

Nvm, Extremely goofy project configuration here and classpath issues with much older versions. Ignore me! -Original Message- From: Jordon Saardchit [mailto:[EMAIL PROTECTED] Sent: Thursday, August 21, 2008 11:54 AM To: java-user@lucene.apache.org Subject: QueryParser Default Operator T

Re: QueryParser: if key contains a colon

This should help http://lucene.apache.org/java/docs/queryparsersyntax.html Erick On Dec 14, 2007 7:28 AM, Helmut Jarausch <[EMAIL PROTECTED]> wrote: > Hi, > > how can one search for a key containing a colon when > using QueryParser (with WhitespaceAnalyzer) > > E.g. > searching for 'abc:def'

Re: QueryParser and NGrams

12 okt 2007 kl. 03.09 skrev Chris Hostetter: : No, sorry, I'm still confused. It ought to be a term queries? : > > System.out.println(new QueryParser("f", new Analyzer() { : > > public TokenStream tokenStream(String string, Reader reader) { : > > return new NGramTokenFilter(new Standard

Re: QueryParser and NGrams

: No, sorry, I'm still confused. It ought to be a term queries? : > > System.out.println(new QueryParser("f", new Analyzer() { : > > public TokenStream tokenStream(String string, Reader reader) { : > > return new NGramTokenFilter(new StandardTokenizer(reader), 2, 5); : > > } : > > }).pars

Re: QueryParser and NGrams

No, sorry, I'm still confused. It ought to be a term queries? -- the flooding troll 11 okt 2007 kl. 20.40 skrev Karl Wettin: I now realize that that phrase makes sense, and that it was another "feature" in my code that confused me. So, forget about it. Bada bing, bada bom. -- karl 1

Re: QueryParser and NGrams

I now realize that that phrase makes sense, and that it was another "feature" in my code that confused me. So, forget about it. Bada bing, bada bom. -- karl 11 okt 2007 kl. 19.47 skrev Karl Wettin: I don't understand, why does the following code create 2 phrase queries instead of 20 term

Re: 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 analyser i get only " track " and not "

Re: queryparser

Well, I'd suggest the first thing you do is remove your custom tokenizer and see what results you get with one of the normal parsers. Then creep up on your custom analyzer bit by bit. Otherwise, it's almost impossible to figure out what's going on except by setting breakpoints in your analyzer an

Re: queryparser

On 6/29/07, Erick Erickson <[EMAIL PROTECTED]> wrote: 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 > si

Re: queryparser

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); System.out.println(que);

Re: queryparser

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 : QueryParser qp = new

Re: QueryParser stripping special char

1) the API you are using indicates you are using a fairly old version of Lucene ... I strongly urge you to upgrade, as there have been many improvements and bug fixes ... three have also beeen many methods deprecated and removed, if you start using an old version now (with it's old methods) it wil

Re: QueryParser stripping special char

Hi Harini; If you are already indexing phone numbers in a separate field, you could also consider indexing the area code as a separate field too. This might give better performance depending on the size of your index. Ozgur On 6/12/07, Harini Raghavan <[EMAIL PROTECTED]> wrote: Hi All, I am

Re: QueryParser stripping special char

Hi Harini, Harini Raghavan wrote: > I am trying to create a lucene query to search for companies based on > areacode. The phone no. is stored in the lucene index in the form of > '415-567-2323'. I need to create a query like +areaCode:"415-". But the > QueryParser is stripping off the hyphen(-). >

Re: QueryParser, PrefixQuery, and case sensitivity

Erick, Thanks for the advice. I will take a look at PerFieldAnalyzerWrapper to see if I want to take this on. For my case, I have to use mexed case for a couple of fields since case really does matter for them (ie apple is not the same as Apple), and I actually don't want users to find the d

Re: QueryParser, PrefixQuery, and case sensitivity

Look at PerFieldAnalyzerWrapper. It allows you to use different analyzers on different fields during the query parsing phase. But I wouldn't go there if you don't have to. I suspect you'll spend a LOT of time tracking down errors in your use of a mixed case index. If for no other reason than your

Re: QueryParser and auto wildcard searches

Hi! I am new to Lucene and I am trying to customise the query parser to default to wildcard searches. For example, if the user types in "fenc", it should find "fence" and "fencing" and "fences" and "fenced". Looks like stemming to me! Maybe you should consider using a stemming analyzer instea

Re: QueryParser oddity with PrefixQuery

I agree, might be a redundant check now. This test was added when the query parser was enhanced to optionally allow leading wild card (revision 468291 ), but this case calls getWildCardQuery(), not getPrefixQuery(). Still, the check seems harmless - sort of defensive - protecting against the case

Re: QueryParser bug?

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,

Re: QueryParser bug?

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

Re: QueryParser bug?

: 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

Re: QueryParser bug?

Chris Hostetter wrote: i'm not very familiar with this issue, but are you using setAllowLeadingWildcard(true) ? ... if not it definitely won't work. That's not the issue. (I've modified QP to allow "minWildcardPrefix" rather than just on/off), but the original QP shows the problem with setAl

Re: QueryParser bug?

i'm not very familiar with this issue, but are you using setAllowLeadingWildcard(true) ? ... if not it definitely won't work. : Date: Thu, 22 Feb 2007 15:36:43 +1100 : From: Antony Bowesman <[EMAIL PROTECTED]> : Reply-To: java-user@lucene.apache.org : To: java-user@lucene.apache.org : Subject: Q

Re: QueryParser explicit and implicit search operator

rüngliche Nachricht- Von: Erick Erickson [mailto:[EMAIL PROTECTED] Gesendet: Montag, 19. Februar 2007 14:45 An: java-user@lucene.apache.org Betreff: Re: QueryParser explicit and implicit search operator <<>> Because some documents contain "Lucene" but not "Query" an

Re: QueryParser explicit and implicit search operator

h query "Query OR Lucene" 316 results and came to the guess that it seems to be fixed for a query like "X OR Y"! How else would you explain the 316 search results, when the results for each single queries "Lucene" and "Query" is lesser than 316? Ja

Re: QueryParser explicit and implicit search operator

On Feb 16, 2007, at 1:53 PM, Karimi-Tabatabaie Jamal wrote: For my problem there seems to exist a lucence Bug (http://issues.apache.org/jira/browse/LUCENE-167) but also it seems that it's solved in the Lucene integration on site http:// www.lucenebook.com. Where do you see the problem solve

Re: QueryParser Is Badly Broken

In a way that certainly needs more testing (haven't had the time), but here is the gist: I modified the SpanNotQuery to allow a certain number of span crossings-- making it something of a WithinSpanQuery. So instead of just being able to say find "something" and "something else" and don't let it

Re: QueryParser Is Badly Broken

Mark, you wrote: > > On another note...http://famestalker.com > > ... > > http://famestalker.com/devwiki/ Could you explain how "Paragraph/Sentence Proximity Searching" is implemented in Qsol? Regards, Paul Elschot - To unsub

Re: QueryParser syntax French Operator : DONE!

Thanks Mark! I have to mention Benoit Mercier here who worked with me so we could understand how to expand a term and use TOKEN_MGR_DECLS. Patrick On 10/13/06, Mark Miller <[EMAIL PROTECTED]> wrote: Great work Patrick. I was unfamiliar with the use of TOKEN_MGR_DECLS. Looks like a powerfull f

Re: QueryParser syntax French Operator : DONE!

Submitted to Jira with key LUCENE-682 Patrick Grant Ingersoll wrote: Hi Patrick, Thanks for the work. Create a bug in JIRA and upload a patch (see svn diff). See the Wiki for information on how to contribute. Thanks, Grant -

Re: QueryParser syntax French Operator : DONE!

Great work Patrick. I was unfamiliar with the use of TOKEN_MGR_DECLS. Looks like a powerfull feature for dynamic token selection. Thanks a lot, - Mark On 10/13/06, Patrick Turcotte <[EMAIL PROTECTED]> wrote: Mark Miller wrote: > Could you say in a few words what you did to accomplish this? I k

Re: QueryParser syntax French Operator : DONE!

Mark Miller wrote: Could you say in a few words what you did to accomplish this? I know that you mentioned you used a resource bundle, but what part of the code reads this resource bundle? What method did you use to get by the JavaCC issues? Basically: * I used TOKEN_MGR_DECLS to decla

Re: QueryParser Is Badly Broken

I realize my statement of dread may be news to some; here are my references. QueryParser not handling queries containing AND and OR http://issues.apache.org/jira/browse/LUCENE-167 Query Parser flags clauses with explicit OR as required when followed by explicit AND http://issues.apache.org/jir

Re: QueryParser syntax French Operator : DONE!

Had this page open for somebody else: http://wiki.apache.org/jakarta-lucene/HowToContribute Otis - Original Message From: Patrick Turcotte <[EMAIL PROTECTED]> To: java-user@lucene.apache.org Sent: Friday, October 13, 2006 10:40:27 AM Subject: QueryParser syntax French Operator : DONE!

Re: QueryParser syntax French Operator : DONE!

Could you say in a few words what you did to accomplish this? I know that you mentioned you used a resource bundle, but what part of the code reads this resource bundle? What method did you use to get by the JavaCC issues? thanks, -Mark On 10/13/06, Patrick Turcotte <[EMAIL PROTECTED]> wrote:

Re: QueryParser syntax French Operator : DONE!

Hi Patrick, Thanks for the work. Create a bug in JIRA and upload a patch (see svn diff). See the Wiki for information on how to contribute. Thanks, Grant On Oct 13, 2006, at 10:40 AM, Patrick Turcotte wrote: Hello! This may not be the best place for this message, sorry if this is the

Re: QueryParser Is Badly Broken

On another note...http://famestalker.com /devwik/ will be done soon...I only The url gives a not found 404 error here. Due to a typo on my part: http://famestalker.com/devwiki/ On 10/13/06, Paul Elschot <[EMAIL PROTECTED]> wrote: On Friday 13 October 2006 01:55, Mark Miller wrote: > The

Re: QueryParser Is Badly Broken

On Friday 13 October 2006 01:55, Mark Miller wrote: > There is also the Surround Query Parser in contrib by the way...I would bet > that Paul will tell you that it does not have these issues. I can't wait to Indeed. > see the replies on this one...I didn't realize that the QueryParser had > these

Re: QueryParser Is Badly Broken

On Oct 12, 2006, at 7:11 PM, Renaud Waldura wrote: I'm developing an application used by scientists -- people who have a pretty good idea of what logic is -- and they were shocked to find out that neither of these queries return the same results: 1- banana AND apple OR orange 2- banana AND

Re: QueryParser Is Badly Broken

Renaud Waldura wrote: While we are also developing a query-building UI, users must be able to enter text queries as well. What do other folks do? I mean, this is pretty bad. I can hardly go back to my scientists and tell them Lucene is unable to handle 2 boolean operators, that they should pare

Re: QueryParser Is Badly Broken

There is also the Surround Query Parser in contrib by the way...I would bet that Paul will tell you that it does not have these issues. I can't wait to see the replies on this one...I didn't realize that the QueryParser had these problems and am a bit skeptical...unfortunately I am away from home

RE: QueryParser syntax French Operator

runtime using the ResourceBundle paradigm. I'll keep you posted. Patrick > -Message d'origine- > De : karl wettin [mailto:[EMAIL PROTECTED] > Envoyé : 8 octobre, 2006 10:14 > À : java-user@lucene.apache.org > Objet : Re: QueryParser syntax French Operator > >

Re: QueryParser syntax French Operator

On 10/8/06, Otis Gospodnetic <[EMAIL PROTECTED]> wrote: Hi Patrick, If I were trying to do this, I'd modify QueryParser.jj to construct the grammar for boolean operators based on something like Locale (or LANG env. variable?). I'd try adding code a la: en_AND = AND en_OR = OR en_NOT = NOT fr_

Re: QueryParser syntax French Operator

Hi Patrick, If I were trying to do this, I'd modify QueryParser.jj to construct the grammar for boolean operators based on something like Locale (or LANG env. variable?). I'd try adding code a la: en_AND = AND en_OR = OR en_NOT = NOT fr_AND = ET fr_OR = OU fr_NOT = SAUF And then: if (locale is

Re: QueryParser syntax French Operator

I've started to look into this (and the whole javacc syntax) I'll keep you posted on my results. Patrick Erik Hatcher wrote: Currently AND/OR/NOT are hardcoded into the .jj file. A patch to make this configurable would be welcome! Erik On Oct 3, 2006, at 11:15 AM, Patrick Turcotte w

Re: QueryParser syntax French Operator

On Oct 4, 2006, at 2:18 AM, Ronnie Kolehmainen wrote: Wouldn't the easiest fix be to just alter the users query string before passing it to queryparser (moving the semantics of your search app outside of lucene)? Something like: str.replaceAll(" ET ", " AND ").replaceAll(" OU ", " OR ").

Re: QueryParser syntax French Operator

Wouldn't the easiest fix be to just alter the users query string before passing it to queryparser (moving the semantics of your search app outside of lucene)? Something like: str.replaceAll(" ET ", " AND ").replaceAll(" OU ", " OR ").replaceAll(" SAUF ", " NOT ") Citerar Mark Miller <[EMAIL PROT

  1   2   >