the remaining non-ascii symbols.
However, it does cause odd behaviour in Wildcard Queries. e.g.:
The query title:todesmä* matches todesmarsch, which it should not, because
an ä is supposed to be replaced with an ae, however, it also matches
todesmärchen, as it should.
The query title:todesmär still matches
Hello,
I am having a bit of a problem with Wildcard queries and I don't know how
to pin it down yet. I have a suspect, but I kind find an error in it, one
of the filters in the respective search field.
The problem is that when I do a wildcard query:
title:todesmä*
it does return a result
@lucene.apache.org
Subject: Avoiding wildcard queries using edismax query parser
Hello all,
Currently we are using edismax query parser in an internal application, we've
detected that some wildcard queries including * are causing some performance
issues and for this particular case we're not interested
: Friday, January 23, 2015 8:26:48 AM
Subject: RE: Avoiding wildcard queries using edismax query parser
Here's a Jira for this: https://issues.apache.org/jira/browse/SOLR-3031
I've attached a patch there that might be useful for you.
-Michael
-Original Message-
From: Jorge Luis Betancourt
,
The query gets translated into a MatchAllDocsQuery, which I think happens
before the textual analysis.
- Original Message -
From: Jack Krupansky jack.krupan...@gmail.com
To: solr-user@lucene.apache.org
Sent: Friday, January 23, 2015 12:02:44 AM
Subject: Re: Avoiding wildcard queries
Hello all,
Currently we are using edismax query parser in an internal application, we've
detected that some wildcard queries including * are causing some performance
issues and for this particular case we're not interested in allowing any user
to request all the indexed documents.
This could
...@uci.cu wrote:
Hello all,
Currently we are using edismax query parser in an internal application, we've
detected that some wildcard queries including * are causing some
performance issues and for this particular case we're not interested in
allowing any user to request all the indexed
...@uci.cu wrote:
Hello all,
Currently we are using edismax query parser in an internal application,
we've detected that some wildcard queries including * are causing some
performance issues and for this particular case we're not interested in
allowing any user to request all the indexed documents
,
Regards,
- Original Message -
From: Alexandre Rafalovitch arafa...@gmail.com
To: solr-user solr-user@lucene.apache.org
Sent: Thursday, January 22, 2015 4:46:08 PM
Subject: Re: Avoiding wildcard queries using edismax query parser
I suspect the special characters get caught before
going to test with a custom search component.
Thanks for the quick response Alex,
Regards,
- Original Message -
From: Alexandre Rafalovitch arafa...@gmail.com
To: solr-user solr-user@lucene.apache.org
Sent: Thursday, January 22, 2015 4:46:08 PM
Subject: Re: Avoiding wildcard queries
the textual analysis.
- Original Message -
From: Jack Krupansky jack.krupan...@gmail.com
To: solr-user@lucene.apache.org
Sent: Friday, January 23, 2015 12:02:44 AM
Subject: Re: Avoiding wildcard queries using edismax query parser
The dismax query parser does not support wildcards. It is designed
;foobarquot; OR text:quot;foobarquot;) AND
last_modified:[* TO *}*
* doc id=605/*
* /query*
*/elevate*
Does this file support wildcard queries? Is there any solution how to
achieve this, or do I have to manipulate result
xml from solr to change result order?
P.S. I'm using Solr 4.6 on Windows 7 x64
Hello everyone,
I have written custom analyzer for indexing and querying data from solr
indexes.
Now i would like to enable wildcard search with this custom analyzer only.
Please guide me on how to enable this feature?
Many Thanks,
Dhaivat
Hello,
I have a problem with configuring custom char filter. When there are no
wildcards in query then my filter is invoked. When there are wildcards, my
filter is not invoked.
It is possible to configure charFilter to be used with wildcard queries? I
can see than with wildcards
char filter. When there are no
wildcards in query then my filter is invoked. When there are wildcards, my
filter is not invoked.
It is possible to configure charFilter to be used with wildcard queries? I
can see than with wildcards, TokenizerChain.charFilters is null.
configuration:
analyzer type
tokenizers?
--
View this message in context:
http://lucene.472066.n3.nabble.com/Wildcard-queries-and-custom-char-filter-tp4107241p4107252.html
Sent from the Solr - User mailing list archive at Nabble.com.
in context:
http://lucene.472066.n3.nabble.com/Wildcard-queries-and-custom-char-filter-tp4107241p4107275.html
Sent from the Solr - User mailing list archive at Nabble.com.
Hi everyone.
I came across another need for term extraction: I want to find pairs of
words that appear in queries together. All of the clustering work is
ready. and the only hole is how to get the basic terms from the query.
Nobody tried it before? There is no clean way to do it?
On Tue, May
Hi.
Searching terms with wildcard in their start, is solved with
ReversedWildcardFilterFactory. But, what about terms with wildcard in both
start AND end?
This query is heavy, and I want to disallow such queries from my users.
I'm looking for a way to cause these queries to fail.
I guess there
You are right that starting to parse the query before the query component
can get soon very ugly and complicated. You should take advantage of the
flex parser, it is already in lucene contrib - but if you are interested in
the better version, look at
Thanks Roman.
Based on some of your suggestions, will the steps below do the work?
* Create (and register) a new SearchComponent
* In its prepare method: Do for Q and all of the FQs (so this
SearchComponent should run AFTER QueryComponent, in order to see all of the
FQs)
* Create
Hi Issac,
it is as you say, with the exception that you create a QParserPlugin, not a
search component
* create QParserPlugin, give it some name, eg. 'nw'
* make a copy of the pipeline - your component should be at the same place,
or just above, the wildcard processor
also make sure you are
I don't want to affect on the (correctness of the) real query parsing, so
creating a QParserPlugin is risky.
Instead, If I'll parse the query in my search component, it will be
detached from the real query parsing, (obviously this causes double
parsing, but assume it's OK)...
On Tue, May 28,
class=solr.LowerCaseFilterFactory/
/analyzer
/fieldType
I see that wildcard queries are not analyzed at query time, which could be the
source of my issue, but I read conflicting advice on the interwebs. I read
also that this might have changed in 3.6, but I am unable to determine if my
/
filter class=solr.SynonymFilterFactory synonyms=synonyms.txt
ignoreCase=true expand=true/
filter class=solr.LowerCaseFilterFactory/
/analyzer
/fieldType
I see that wildcard queries are not analyzed at query time, which could be
the source of my issue, but I read conflicting
...@appinions.com]
Sent: Wednesday, June 27, 2012 11:11 AM
To: solr-user@lucene.apache.org
Subject: Re: Wildcard queries on whole words
Hi Michael,
I solved a similar issue by reformatting my query to do an OR across an exact
match or a wildcard query, with the exact match boosted.
HTH,
Michael Della
formulated your query)?
Thanks!
Mike
-Original Message-
From: Michael Della Bitta [mailto:michael.della.bi...@appinions.com]
Sent: Wednesday, June 27, 2012 11:11 AM
To: solr-user@lucene.apache.org
Subject: Re: Wildcard queries on whole words
Hi Michael,
I solved a similar issue
[mailto:michael.della.bi...@appinions.com]
Sent: Wednesday, June 27, 2012 11:11 AM
To: solr-user@lucene.apache.org
Subject: Re: Wildcard queries on whole words
Hi Michael,
I solved a similar issue by reformatting my query to do an OR across an exact
match or a wildcard query, with the exact
: Wildcard queries on whole words
I am researching an issue w/ wildcard searches on complete words in 3.5.
For example, searching for kloster* returns klostermeyer, but
klostermeyer* returns nothing.
The field being queried has the following analysis chain (standard
'text_general'):
fieldType name
Any help on this? I am really stuck on a client project. I need to
know how scoring works with wildcard queries under SOLR 3.2.
Thanks
Bob
On Mon, Mar 5, 2012 at 4:22 PM, Robert Stewart bstewart...@gmail.com wrote:
How is scoring affected by wildcard queries? Seems when I use a
wildcard
/8/12, Robert Stewart bstewart...@gmail.com wrote:
From: Robert Stewart bstewart...@gmail.com
Subject: Re: wildcard queries with edismax and lucene query parsers
To: solr-user@lucene.apache.org
Date: Thursday, March 8, 2012, 4:21 PM
Any help on this? I am really
stuck on a client project. I
=solr.WhitespaceTokenizerFactory /
filter class=solr.LowerCaseFilterFactory /
/analyzer
/fieldType
--- On Thu, 3/8/12, Robert Stewart bstewart...@gmail.com wrote:
From: Robert Stewart bstewart...@gmail.com
Subject: Re: wildcard queries with edismax and lucene query parsers
How is scoring affected by wildcard queries? Seems when I use a
wildcard query I get all constant scores in response (all scores =
1.0). That occurs with both edismax as well as lucene query parser.
I am trying to implement auto-suggest feature so I need to use wild
card to return all results
1. Is there any specific reason why the FastVectorHighlighter does not
provide support for multiterm(wildcard) queries ?
2. What are the other constraints when using FastVectorHighlighter ?
FVH used to have typical constrains:
1. supports only TermQuery and PhraseQuery (and
BooleanQuery
Hi,
I am currently evaluating the FastVectorHighlighter in a Solr search based
project and have a couple of questions
1. Is there any specific reason why the FastVectorHighlighter does not
provide support for multiterm(wildcard) queries ?
2. What are the other constraints when using
(11/09/09 6:16), Rahul Warawdekar wrote:
Hi,
I am currently evaluating the FastVectorHighlighter in a Solr search based
project and have a couple of questions
1. Is there any specific reason why the FastVectorHighlighter does not
provide support for multiterm(wildcard) queries ?
2. What
?
- Kári
- Original Message -
From: Matti Oinas matti.oi...@gmail.com
To: solr-user@lucene.apache.org
Sent: Tuesday, 11 January, 2011 12:47:52 PM
Subject: Re: solr wildcard queries and analyzers
This might be the solution.
http://lucene.apache.org/java/3_0_2/api/contrib-misc/org/apache
Oinas matti.oi...@gmail.com
To: solr-user@lucene.apache.org
Sent: Tuesday, 11 January, 2011 12:47:52 PM
Subject: Re: solr wildcard queries and analyzers
This might be the solution.
http://lucene.apache.org/java/3_0_2/api/contrib-misc/org/apache/lucene/queryParser/analyzing
January, 2011 12:47:52 PM
Subject: Re: solr wildcard queries and analyzers
This might be the solution.
http://lucene.apache.org/java/3_0_2/api/contrib-misc/org/apache/lucene/queryParser/analyzing/AnalyzingQueryParser.html
2011/1/11 Matti Oinas matti.oi...@gmail.com:
Sorry, the message
Hi,
I am having a problem with the fact that no text analysis are performed on
wildcard queries. I have the following field type (a bit simplified):
fieldType name=text class=solr.TextField positionIncrementGap=100
analyzer
tokenizer class=solr.WhitespaceTokenizerFactory
if I search for sjalf*). I know people have been having a
similar problem with the case sensitivity of wildcard queries and most often
the solution seems to be to lowercase the string before passing it on to
solr, which is not exactly an optimal solution (yet a simple one in that
case
.
2011/1/11 Kári Hreinsson k...@gagnavarslan.is:
Hi,
I am having a problem with the fact that no text analysis are performed on
wildcard queries. I have the following field type (a bit simplified):
fieldType name=text class=solr.TextField positionIncrementGap=100
analyzer
that no text analysis are performed on
wildcard queries. I have the following field type (a bit simplified):
fieldType name=text class=solr.TextField positionIncrementGap=100
analyzer
tokenizer class=solr.WhitespaceTokenizerFactory /
filter class=solr.TrimFilterFactory
believe this well help me support fuzzy search in future as well.
So my question is does edismax support wildcard queries? I could not
understand by looking at the source code though.
Thanks
Swapnonil Mukherjee
It does support wildcard queries - we are using that feature from
edismax
-Original Message-
From: Swapnonil Mukherjee [mailto:swapnonil.mukher...@gettyimages.com]
Sent: Thursday, November 18, 2010 1:39 AM
To: solr-user@lucene.apache.org
Subject: Does edismax support wildcard queries
/browse/SOLR-2058
to the apache-solr-1.4.1 as using the trunk is something which we cannot do.
On 18-Nov-2010, at 7:28 PM, Thumuluri, Sai wrote:
It does support wildcard queries - we are using that feature from
edismax
-Original Message-
From: Swapnonil Mukherjee
/browse/SOLR-756
2. Or start using the Solr trunk which will allow me to switch to edismax. I am
specially hopeful of moving to solr trunk and using edismax as I believe this
well help me support fuzzy search in future as well.
So my question is does edismax support wildcard queries? I could
Hi folks,
what's the idea behind the fact that no text analysis (e.g. lowercasing)
is performed on wildcarded search terms?
In my context this behaviour seems to be counter-intuitive (I guess
that's the case in the majority of applications) and my application
needs to lowercase any input
we can use stemming as an example:
lets say your query is c?ns?st?nt?y
how will this match consistently, which the porter stemmer
transforms to 'consistent'.
furthermore, note that i replaced the vowels with ?'s here. The porter
stemmer doesnt just rip stuff off the end, but attempts to guess
I absolutely consider this a bug too. Cast your vote:
https://issues.apache.org/jira/browse/SOLR-219
~ David
On May 21, 2010, at 10:11 AM, Sascha Szott wrote:
Hi folks,
what's the idea behind the fact that no text analysis (e.g. lowercasing)
is performed on wildcarded search terms?
In
Hi Robert,
thanks, you're absolutely right. I should better refine my initial
question to: What's the idea behind the fact that no *lowercasing* is
performed on wildcarded search terms if the field in question contains a
LowercaseFilter in its associated field type definition?
-Sascha
this lowercasing can 'sort of work' (depending on your analysis, and
even language, not all case folding is as simple as english).
But the more general problem cannot be a bug, as its mathematically
not possible to do with queries like wildcard that allow an infinite
language, and non-reversible
I honestly do not know the rationale behind this in Solr, except to
say similar problems exist even if you reduce the scope to just
casing:
For example, if you are using a german stemmer, it will case-fold ß to
'ss' (such that it will match SS).
So doing some lowercasing at query-time will not
On May 21, 2010, at 10:35 AM, Robert Muir wrote:
I honestly do not know the rationale behind this in Solr, except to
say similar problems exist even if you reduce the scope to just
casing:
Then why are you talking about stemming in the following example? We know
stemming is problematic with
On Fri, May 21, 2010 at 10:40 AM, Smiley, David W. dsmi...@mitre.org wrote:
Then why are you talking about stemming in the following example? We know
stemming is problematic with wildcard searching. But casing... I argue not.
I just mentioned an example stemmer that properly case-folds
Hi Kurt. I'm the author of those JIRA issues. I'm glad you have interest in
them. Please vote for them if you have not done so already. I updated
SOLR-758 and I hope it works out okay for you. If you have further questions,
please comment on the relevant issues.
~ David Smiley
Author:
On Tue, Aug 25, 2009 at 3:00 AM, Kurt N. kurt.nordst...@unt.edu wrote:
Hello all.
We have a situation in the requirements for our project that make it
desireable to be able to perform a DisMax query with wildcard (* and ?)
characters in it.
We are using the standard release (not nightly)
, it seemed that the new code from SOLR-758 was
looking for a function called getNonLocalParams(), which, after grep'ing
the source, doesn't seem to exist in the Solr codebase.
At this point, any help would be welcome. Our goal is to get DisMax working
with wildcard queries, so if we're going about
be a
bonus). For this, I've tried implementing the suggestion to store
reverse strings as well as the correct strings for the metadata field.
All leading wildcard queries like *abc and searched as cba* against
the reversed metadata field. So far so good. Thank you :)
But now, I ran
--
Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch
- Original Message
From: Neal Richter nrich...@gmail.com
To: solr-user@lucene.apache.org
Sent: Wednesday, January 28, 2009 3:10:29 AM
Subject: Re: Customizing Solr to handle Leading Wildcard queries
Oh wait.. looks like Otis
Hi,
Not being able to perform Leading Wildcard queries is a major handicap.
I want to be able to perform searches like *.pdf to fetch all pdf
documents from Solr.
I have found quite a few threads on this topic and one of the solutions
was that this feature can be enabled by adding
On Jan 15, 2009, at 8:23 AM, Jana, Kumar Raja wrote:
Not being able to perform Leading Wildcard queries is a major
handicap.
I want to be able to perform searches like *.pdf to fetch all pdf
documents from Solr.
For this particular case, I recommend indexing the document type
: Thursday, January 15, 2009 7:59 PM
To: solr-user@lucene.apache.org
Subject: Re: Customizing Solr to handle Leading Wildcard queries
On Jan 15, 2009, at 8:23 AM, Jana, Kumar Raja wrote:
Not being able to perform Leading Wildcard queries is a major
handicap.
I want to be able to perform searches
as reverseField:fdp.oof. Now when someone does a search on
reverseField, like reverseField:*oo.pdf, you reverse the query to be:
fdp.oo*
I believe some of the DBMSs kept a separate reverse b-tree to handle
leading wildcard queries.
And obviously this technique is harder to put in place for arbitrary
sections of text
--
Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch
- Original Message
From: Jana, Kumar Raja kj...@ptc.com
To: solr-user@lucene.apache.org
Sent: Thursday, January 15, 2009 9:49:24 AM
Subject: RE: Customizing Solr to handle Leading Wildcard queries
Hi Erik,
Thanks
of:
1.0 = boost
1.0 = queryNorm
/str
--
View this message in context:
http://www.nabble.com/boost-ignored-with-wildcard-queries-tp15703334p15703334.html
Sent from the Solr - User mailing list archive at Nabble.com.
--
View this message in context:
http://www.nabble.com/boost
fuzzy queries may have been fixed in lucene to not exceed the
boolean query clause limit.
WildCard queries: no good reason... didn't really need it, so I never
got around to it :-)
-Yonik
~ David Smiley
Yonik Seeley wrote:
On Tue, Feb 26, 2008 at 7:23 PM, Head [EMAIL PROTECTED] wrote:
Using
: Using the StandardRequestHandler, it appears that the index boost values
are
: ignored when the query has a wildcard in it. For example, if I have 2
: doc's and one has a boost of 1.0 and another has a boost of 10.0, then I
: do a search for bob*, both records will be returned with
)
ConstantScoreQuery([EMAIL PROTECTED]), product of:
1.0 = boost
1.0 = queryNorm
/str
--
View this message in context:
http://www.nabble.com/boost-ignored-with-wildcard-queries-tp15703334p15703334.html
Sent from the Solr - User mailing list archive at Nabble.com.
= queryNorm
/str
str name=id=24317,internal_docid=2217
1.0 = (MATCH)
ConstantScoreQuery([EMAIL PROTECTED]), product of:
1.0 = boost
1.0 = queryNorm
/str
--
View this message in context:
http://www.nabble.com/boost-ignored-with-wildcard-queries-tp15703334p15703334.html
Sent from the Solr - User
Yes. I definitely cannot get this to work for terms that have spaces
in them.
++
| Matthew Runo
| Zappos Development
| [EMAIL PROTECTED]
| 702-943-7833
++
On Aug 8, 2007, at
On 8/8/07, Matthew Runo [EMAIL PROTECTED] wrote:
Yes. I definitely cannot get this to work for terms that have spaces
in them.
Did you try escaping the space with a backslash?
I think this should be made easier for future releases.
One way is something like
q=!prefix field=foohey, no escaping
72 matches
Mail list logo
