On Wednesday 24 November 2004 08:16, Morus Walter wrote:
Lucene itself doesn't handle wildcards within phrases.
This can be added using PhrasePrefixQuery (which is slightly misnamed):
http://jakarta.apache.org/lucene/docs/api/org/apache/lucene/search/PhrasePrefixQuery.html
Regards
Daniel
Hi Daniel,
I couldn't figure out how to use the PharsePrefixQuery with a phase like java*
developer. It only provides method to add terms. Can a term contain wildcard
character in lucene?
Thanks,
Terence
On Wednesday 24 November 2004 08:16, Morus Walter wrote:
Lucene itself doesn't
Hi Morus,
I want to search for the string like below:
- java developer
- javascript developer
By searching java*, it will return more than I want. That's why I am thinking
java* developer.
Terence
Terence Lai writes:
Look likes that the wildcard query disappeared. In fact, I am
Hi all,
I am trying to use the QueryParser.parse() to parse a query string like java*
developer. Note that I want the wildcard string, java*, followed by the word
developer. The following is the code.
-
String qryStr = \java* developer\;
String fieldname = text;
StandardAnalyzer
Terence Lai writes:
Look likes that the wildcard query disappeared. In fact, I am expecting
text:java* developer to be returned. It seems to me that the QueryParser
cannot handle the wildcard within a quoted String.
That's not just QueryParser.
Lucene itself doesn't handle wildcards
To: Lucene Users List
Subject: Re: HOWTO USE SORT on QUERY PARSER :(
example:
query = QueryParser.parse(queryString, FIELD_CONTENTS, analyzer);
Sort sort =new Sort();
sort.setSort(FIELD_DATE,true);
//hits = searcher.search(query,sort);
hits
On Jun 9, 2004, at 4:39 PM, David Spencer wrote:
I like the idea of a flexible run-time grammar, but it sounds too
good to be true in a general purpose kinda way.
My idea isn't perfect for humans, but at least lets you use queries
not hard coded.
But in my idealistic view, getting something
]
To: Lucene Users List [EMAIL PROTECTED]
Sent: Thursday, June 10, 2004 5:04 AM
Subject: Re: extensible query parser - Re: Proximity Searches
behavior
On Jun 9, 2004, at 4:39 PM, David Spencer wrote:
I like the idea of a flexible run-time grammar, but it sounds
too
good to be true
On Jun 10, 2004, at 10:26 AM, Terry Steichen wrote:
Erik,
When is Lucene in Action scheduled to be out?
To add to what Otis said - I've been working feverishly to come to
terms with SpanQuery*, the new sorting feature, Highlighter, Nutch
analysis and much more. Lucene in Action will be accurate
] example of registration
register( substring, new SubstringQP()); // instead of prefix matches
allows term anywhere
register( span, new SurroundQP());
register( syn, new SynonymExpanderQP()); // expands a word to include
synonyms
[4] syntax
normal query parser syntax but add something else like NAME
:
Subject:Re: RE: RE: Query parser and minus signs
On May 26, 2004, at 10:48 AM, [EMAIL PROTECTED] wrote:
Query: hsbc -language:zh-HK
Parsed query: (contents:hsbc -language:zh -contents:hk) (keywords:hsbc
-language:zh -keywords:hk) (title:hsbc -language:zh -title:hk)
(language:hsbc
looks OK at least to a relative beginner like myself), and also
through the search code but I'm still none the wiser.
Am I doing something wrong, or have I completely missed the point ??
To:Alex BOURNE/IBEU/[EMAIL PROTECTED]
cc:
bcc:
Subject:RE: RE: Query parser and minus signs
??
To:Alex BOURNE/IBEU/[EMAIL PROTECTED]
cc:
bcc:
Subject:RE: RE: Query parser and minus signs
remember luke does not display the indexed tokens but the stored
field. So
you would expect to see en-uk in the field.
doc.add(Field.Keyword(locale,test-uk));
are you adding to the document like
it just become
part of the query??
Erik Hatcher [EMAIL PROTECTED] on 26 May 2004 15:11
Please respond to Lucene Users List [EMAIL PROTECTED]
To:Lucene Users List [EMAIL PROTECTED]
cc:
bcc:
Subject:Re: RE: RE: Query parser and minus signs
What is the value of your Parsed query
On May 26, 2004, at 10:48 AM, [EMAIL PROTECTED] wrote:
Query: hsbc -language:zh-HK
Parsed query: (contents:hsbc -language:zh -contents:hk) (keywords:hsbc
-language:zh -keywords:hk) (title:hsbc -language:zh -title:hk)
(language:hsbc
-language:zh -language:HK)
Hits: 169
Not quite what I was
respond to Lucene Users List [EMAIL PROTECTED]
To:Lucene Users List [EMAIL PROTECTED]
cc:
bcc:
Subject:RE: RE: Query parser and minus signs
Doesn't en UK as a phrase query work?
You're probably indexing it as a text field so it's being tokenised.
-Original Message-
From: [EMAIL
On May 24, 2004, at 4:50 AM, [EMAIL PROTECTED] wrote:
I tried this, but no it does not work. I'm concerned that escaping the
minus symbol does not appear to work. The field is indexed as a
keyword so
is not tokenized - I've checked the contents using luke which confirms
this.
You will need to
Hi All,
I'm using Lucene on a site that has split content with a branch containing
pages in English and a separate branch in Chinese. Some of the chinese
pages include some (untranslatable) English words, so when a search is
carried out in either language you can get pages from the wrong
if you're dealing with locales, why not use java's built in locale syntax (ex: en_UK,
zh_HK)?
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Friday, May 21, 2004 10:36 AM
To: [EMAIL PROTECTED]
Subject: Query parser and minus signs
Hi All
PROTECTED]
cc:
bcc:
Subject:RE: Query parser and minus signs
if you're dealing with locales, why not use java's built in locale syntax
(ex: en_UK, zh_HK)?
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Friday, May 21, 2004 10:36 AM
To: [EMAIL PROTECTED
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, May 21, 2004 11:36 AM
Subject: Query parser and minus signs
Hi All,
I'm using Lucene on a site that has split content with a branch containing
pages in English and a separate branch in Chinese
Doesn't en UK as a phrase query work?
You're probably indexing it as a text field so it's being tokenised.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: 21 May 2004 16:47
To: Lucene Users List
Subject: Memo: RE: Query parser and minus signs
Hmm, we may
Daniel B. Davis writes:
There was a lot of correspondence during December about this.
Is there any further resolution?
There's a patch and I hope it will find it's way into the lucene
sources.
see: http://issues.apache.org/bugzilla/show_bug.cgi?id=25820
Seems I missed the mail about Otis
, one for default or, one for default and).
Maybe it's obvious, but I fail to see it.
As far as the actual patch, I would suspect that a better approach than
using java would be to use precedence operations in the actual parser.
Then you decide to do a complete rewrite of the query parser
Is there another interpretation?
As far as the actual patch, I would suspect that a better approach than
using java would be to use precedence operations in the actual parser.
Then you decide to do a complete rewrite of the query parser.
That's something I wanted to avoid.
Ouch. I
of these, as it handles the default operator
on the same level as AND.
As far as the actual patch, I would suspect that a better approach than
using java would be to use precedence operations in the actual parser.
Then you decide to do a complete rewrite of the query parser.
That's something I
On Dec 30, 2003, at 3:13 PM, Morus Walter wrote:
Hmm. That's be up to the developers.
Don't know how many of them are reading lucene-user.
I suspect we're all here!
QueryParser is Lucene's red-headed step-child. It works well enough,
but it has more than its share of issues. It is almost a
On Tue, Dec 30, 2003 at 03:25:08PM -0500, Erik Hatcher wrote:
On Dec 30, 2003, at 3:13 PM, Morus Walter wrote:
Hmm. That's be up to the developers.
Don't know how many of them are reading lucene-user.
I suspect we're all here!
Great.
QueryParser is Lucene's red-headed step-child. It
decide to do a complete rewrite of the query parser.
That's something I wanted to avoid.
Ouch. I think you might be right. It might be a good idea to move this
discussion to lucene-dev where we'd get more attention from the
developers. This seems more like a developer issue than a user issue
of
serializing an arbitray query to a parsable string in standard query parser
syntax.
So for completeness and compatibility with the current query parser, I would
keep the current behaviour of queries without explicit boolean operators.
The problem for users isn't that big IMHO.
Unless a user
AND or OR
There's some redundancy between all three, and it's quite easy to get
confused.
A consequence of pure boolean operators is, that there won't be a way of
serializing an arbitray query to a parsable string in standard query parser
syntax.
So for completeness and compatibility with the current
my $.02.
Before having patches, I think it's a good idea to agree on what the
right solution is. Most of it is obvious using boolean logic, but we
have some additional requirements like not having a query that only has
a NOT clause. Is this the only exception?
As far as the actual patch, I
implicit priority.
I had a closer look at this and wrote a patch, that implements this by
changing the vector of boolean clauses into a vector of vectors of boolean
clauses in the addClause method of the query parser. A new sub-vector is
created whenever an explicit OR operator is used.
Queries using
Morus Walter writes:
I attached the patch (made against 1.3rc3 but working for 1.3final as well)
and a test program.
Seems the attachments got stripped...
So once again:
The patch:
===File lucene/QueryParser.jj.patch===
*** QueryParser.jj.org Mon Dec 22 11:47:30 2003
---
Hi Dror,
thanks for your answer.
I'm having problems understanding query parsers handling of AND and OR
if there's more than one operator.
E.g.
a OR b AND c
gives the same number of hits as
b AND c
(only scores are different)
This would make sense if all the document that
Message-
From: Morus Walter [mailto:[EMAIL PROTECTED]
Sent: 10 December 2003 09:01
To: Lucene Users List
Subject: Re: Query Parser AND / OR
Hi Dror,
thanks for your answer.
I'm having problems understanding query parsers handling of AND and OR
if there's more than one operator.
E.g
Hi,
I'm having problems understanding query parsers handling of AND and OR
if there's more than one operator.
E.g.
a OR b AND c
gives the same number of hits as
b AND c
(only scores are different)
and
a AND b OR c AND d
seems to be equivalent to
a AND b AND C AND d
which doesn't seem logical
On Tue, Dec 09, 2003 at 10:57:51AM +0100, Morus Walter wrote:
Hi,
I'm having problems understanding query parsers handling of AND and OR
if there's more than one operator.
E.g.
a OR b AND c
gives the same number of hits as
b AND c
(only scores are different)
This would make sense if
Hello.
I've made a Filter which recognizes special words and return them in a
boosted form, in a QueryParser sense.
For instance, when the filter receives special_word, it returns
special_word^3, so as to boost it.
The problem is that the QueryParser understands the boost syntax when the
string
On Wednesday, November 12, 2003, at 10:53 AM, MOYSE Gilles (Cetelem)
wrote:
Hello.
I've made a Filter which recognizes special words and return them in a
boosted form, in a QueryParser sense.
For instance, when the filter receives special_word, it returns
special_word^3, so as to boost it.
The
Hi,
im currently trying to understand how the standard query parser
handles operator precedence in a query like
a OR b AND c OR d
This is output by the toString method as
a +b +c d
so AND seems to have higher precedence than OR
Now if I try to check this and look at
a OR ( b AND c ) OR d
I see
One of my clients is asking for an old-style boolean query search on my keywords
fields. A string might look like this:
oracle admin* and java and oracle and (8.1.6 or 8.1.7) and (solaris or
unix or linux)
There would probably be need for nested parenthesis, although I can't think of
On Friday 28 March 2003 15:48, Shah, Vineel wrote:
One of my clients is asking for an old-style boolean query search on my
keywords fields. A string might look like this:
oracle admin* and java and oracle and (8.1.6 or 8.1.7) and
(solaris or unix or linux)
There would probably be need
Hi,
Is there any way to filter the search based on the modified date. For example, i need
to fetch only those documents whose modified date or or between. Can any one help
me to solve this.
Thanks a ton
Nellai...
Try using the newest release and read the Queryparser syntax.
http://jakarta.apache.org/lucene/docs/queryparsersyntax.html
Escape characters were just added.
--Peter
On 5/29/02 10:53 PM, Harpreet S Walia [EMAIL PROTECTED] wrote:
Hi
I am trying to search words which have characters { ,
Hi
I am trying to search words which have characters { , [ etc in them . I am using the
standard lucene jar (V 1.2-rc4 ).
when i search for the words having these charcters i get a exception saying
org.apache.lucene.queryParser.TokenMgrError: Lexical error at line 1, column 8.
Encountered:
: query parser deafults
I've been looking at the query parser source code and have come to a
loose end.
Not surprising! Many people have a hard time wrapping their
head around
parsers; the logic is not straightforward.
I'm attempting to modify the query parser so that all terms
Hi,
I've been looking at the query parser source code and have come to a loose end.
I'm attempting to modify the query parser so that all terms default to required.
Please can someone advise how to do this.
Thanks,
Richard Taylor
New Scientist Developer
,
William.
From: Peter Carlson [EMAIL PROTECTED]
Reply-To: Lucene Users List [EMAIL PROTECTED]
To: Lucene Users List [EMAIL PROTECTED]
CC: Lucene Developers List [EMAIL PROTECTED]
Subject: Query Parser Syntax documentation now available
Date: Wed, 15 May 2002 22:22:47 -0700
Lucene supports creating
Lucene supports creating your own query syntax, but also provides a default
QueryParser implementation using JavaCC to parse query strings into Lucene
Query objects.
In hopes to provide some better understanding, there is now a Query Parser
Syntax document available which describes the features
50 matches
Mail list logo
