Yes. But You haven’t told us what _type_ of field you’re working with though.
If it’s a “string” type, then ComplexPhraseQueryParser won’t work. Looking
again at your example it looks as though you are using strings. Then try
abc\ d*
Adding debug=query to your url will show you how the query get
Erick,I tried complexqueryparser, still no result.Escape white space, do you
mean to say using "\" ?Thanks,Ahemad
Sent from Yahoo Mail on Android
On Sun, Mar 31, 2019 at 1:22, Erick Erickson wrote:
Try complexphrasequeryparser. If (and only if) you always want to search
from the beginnin
Try complexphrasequeryparser. If (and only if) you always want to search
from the beginning of the content, you might be able to use string rather
than text-based Fields but make sure to escape whitespace...
Best,
Erick
On Sat, Mar 30, 2019, 10:33 ahemad.sh...@yahoo.com.INVALID
wrote:
> Hi ,
>
:iori...@yahoo.com]
Sent: Freitag, 12. August 2016 07:41
To: solr-user@lucene.apache.org; Ribeaud, Christian (Ext)
Subject: Re: Wildcard search not working
Hi Christian,
Please use the following filter before/above the stemmer.
Plus, you may want to add :
Ahmet
On Thursday, Augu
August 2016 16:00
To: solr-user@lucene.apache.org; Ribeaud, Christian (Ext)
Subject: Re: Wildcard search not working
Hi Chiristian,
The query r?che may not return at least the same number of matches as roche
depending on your analysis chain.
The difference is roche is analyzed but r?che don'
; christian
> --
> Christian Ribeaud
> Software Engineer (External)
> NIBR / WSJ-310.5.17
> Novartis Campus
> CH-4056 Basel
>
>
> -----Original Message-
> From: Ahmet Arslan [mailto:iori...@yahoo.com]
> Sent: Donnerstag, 11. August 2016 16:00
> To: solr-user@l
Basel
-Original Message-
From: Ahmet Arslan [mailto:iori...@yahoo.com]
Sent: Donnerstag, 11. August 2016 16:00
To: solr-user@lucene.apache.org; Ribeaud, Christian (Ext)
Subject: Re: Wildcard search not working
Hi Chiristian,
The query r?che may not return at least the same number of matches as
Hi Chiristian,
The query r?che may not return at least the same number of matches as roche
depending on your analysis chain.
The difference is roche is analyzed but r?che don't. Wildcard queries are
executed on the indexed/analyzed terms.
For example, if roche is indexed/analyzed as roch, the qu
Great.
First option worked for me. I was trying with q=abc\sp*... it should be q=abc\
p*
Thanks
-Original Message-
From: Ahmet Arslan [mailto:iori...@yahoo.com]
Sent: Wednesday, June 15, 2016 6:25 PM
To: solr-user@lucene.apache.org; Roshan Kamble
Subject: Re: wildcard search for string
Hi Roshan,
I think there are two options:
1) escape the space q=abc\ p*
2) use prefix query parser q={!prefix f=my_string}abc p
Ahmet
On Wednesday, June 15, 2016 3:48 PM, Roshan Kamble
wrote:
Hello,
I have below custom field type defined for solr 6.0.0
Ok I think I understand your points there. Just clarify say if the term was
"Large increased" and my filters went something like:
Large|increased
Large|increase|increased
large|increase|increased
the final tokens indexed would be large|increase|increased ?
Once again thanks for all the help.
right, prior to 3.6, the standard way to handle wildcards was to,
essentially, pre-analyze the terms that had wildcards. This works
fine for simple filters, things like lowercasing for instance, but
doesn't work so well for things like stemming.
So you're doing what can be done at this point, but
On 10/2/2014 4:33 AM, waynemailinglist wrote:
> Something that is still not clear in my mind is how this tokenising works.
> For example with the filters I have when I run the analyser I get:
> Field: Hello You
>
> Hello|You
> Hello|You
> Hello|You
> hello|you
> hello|you
>
>
> Does this mean th
Many many thanks for the replies - it was helpful for me to start
understanding how this works.
I'm using 3.5 so this goes to explain a lot. What I have done is if the
query contains a * I make the query lowercase before sending to solr. This
seems to have solved this issue given your explanation
Two things:
1> what version of Solr are you using? If it's prior to 3.6, then the
bits that handle applying lowercaseFilter to wildcards isn't in the
code.
2> what do you see if you add &debug=query?
I just tried it with your analysis chain and it seemed to work. Did
you completely blow your ind
If you use "*" you use Multiterm analysis path, which is semi-hidden
and is a lot more limited to the things done with normal tokens:
https://wiki.apache.org/solr/MultitermQueryAnalysis
The Analyzer components that are NOT multiterm aware cannot be used
that way. Looking at: http://www.solr-start.
I'm still stuck on this actually. I would really appreciate any pointers.
If I search for :
query 1: Κώστας
result: Κώστας
query 2: Κώστα*
result:
I've looked at the analyser but I don't really understand what I'm looking
at if I'm honest. It gives the output:
Field (name): title
Field value: Κ
Ahmet - many thanks - I removed the EnglishPorterFilterFactory and reindexed
and this seems to behave as expected now.
Jack - thanks aswell - I'm very much a noob with this, and thats a great
tip.
--
View this message in context:
http://lucene.472066.n3.nabble.com/Wildcard-search-makes-no-sen
The presence of a wildcard in a query term short circuits some portions of
the analysis process. Some token filters like lower case can still be
performed on the query terms, but others, like stemming, cannot. So, either
simplify the analysis (be more selective of what token filters you use), or
On Wed, 2014-10-01 at 13:16 +0200, Wayne W wrote:
> query 2: capit*
> result: Capital Health
>
> query 3: capita*
> result:
You are likely using a stemmer for the field: "Capital Health" gets
indexed as "capit" and "health", so there are no tokens starting with
"capita".
Turn off the stemmer or
Hi,
Probably you have stemmer and it is eating up Capital to capit. Thats the
reason.
Either remove stemmer from analyser chain or add keyword repeat filter.
Ahmet
On Wednesday, October 1, 2014 2:16 PM, Wayne W
wrote:
Hi,
I don't understand this at all. We are indexing some contact names.
Can someone help me out with this issue please?
--
View this message in context:
http://lucene.472066.n3.nabble.com/Wildcard-search-not-working-with-search-term-having-special-characters-and-digits-tp4133385p4133770.html
Sent from the Solr - User mailing list archive at Nabble.com.
Thanks jack for prompt response!
So is there any solution to make this scenario works?
Or wildcard doesn't work with special characters and numerics?
Thanks,
G. Naresh Kumar
--
View this message in context:
http://lucene.472066.n3.nabble.com/Wildcard-search-not-working-with-search-term-havin
Wildcard query only works for single terms. Any embedded special characters
will cause a term to be split into multiple terms at index time. The use of
a wildcard in a query term with embedded special characters will bypass
normal analysis - you need to enter the term exactly as it would be anal
Can some one please help me with this as I am struck with this issue..
--
View this message in context:
http://lucene.472066.n3.nabble.com/Wildcard-search-not-working-with-search-term-having-special-characters-and-digits-tp4133385p4133478.html
Sent from the Solr - User mailing list archive at
Hi,
Forget about patternReplaceCharFilter for a moment. Your example is more clear
this time.
q=titleName:1999/99*
should return following two docs:
d1) JULIUS CAESER (1999/99)
d2) ARABIAN NIGHTS - 1999/99
This is achievable with the following type.
1) MappingCharFilterFactory with mapp
Hi Ahmet,
Let me explain with another scenario .
There is a title -> ARABIAN NIGHTS - 1999/99
Now in autocomplete, if i give 1999/99 , in the backend i append an asterisk
to it and form the solr url thsi way
q=titleName:1999/99*
I get the above mentioned title.- so works perfect
Now lets add
Hi Kashish,
This is confusing. You gave the following example :
query 1999/99* should return RABIAN NIGHTS #01 (1999/99)
However you said "I cannot ignore parenthesis or other special characters..."
Above two contadicts each other.
Since you are after autocomplete you might be interested in th
Hi, Pls help me with this.
--
View this message in context:
http://lucene.472066.n3.nabble.com/Wildcard-search-not-working-if-the-query-conatins-numbers-along-with-special-characters-tp4119608p4121457.html
Sent from the Solr - User mailing list archive at Nabble.com.
Hi Erick,
I understand what you pointing out but the thing is.. this is for
autocomplete feature. I cannot ignore parenthesis or other special
characters as in certain titles like 'A Team of five', if the user fives 'a
team' then titles containing a-team and rest also comes off and this one
gets l
The admin/analysis page is your friend. Taking some time to
get acquainted with that page will save you lots and lots and
lots of time. In this case, you'd have seen that your input
is actually tokenized as (1999/99), parentheses and all as a
_single_ token, so of course searching for 1999/99 would
Hi Ahmet/Erick,
I tried escaping as well. See no luck.
The title am looking for is - ARABIAN NIGHTS #01 (1999/99)
I figured out that if i pass the query as *1999/99* (i.e asterisk not only
at the end but at the beginning as well), It works.
The problem is the braces. I can change my field type
Hi,
By saying escaping I mean this : q=title_autocomplete:1999\/99* It is
different than URL encoding.
http://lucene.apache.org/core/4_6_0/queryparser/org/apache/lucene/queryparser/classic/package-summary.html#Escaping_Special_Characters
If prefix query parser didn't return what you want then
What does it say happens on your admin/analysis page
for that field?
And did you by any chance change your schema without
reindexing everything?
Also, try the TermsComonent to see what tokens are actually
_in_ your index. Schema-browser from the admin page can
help here too.
Best,
Erick
On Tue
Hi Ahmet,
Thanks for your reply.
Yes. I pass my query this way - > q=title_autocomplete:1999%2f99
I tried your way too. But no luck. :(
--
View this message in context:
http://lucene.472066.n3.nabble.com/Wildcard-search-not-working-if-the-query-conatins-numbers-along-with-special-character
Hi Kashish,
What happens when you use this q={!prefix f=title_autocomplete}1999/99
I suspect '/' character is a special query parser character therefore it needs
to be escaped.
Ahmet
On Tuesday, February 25, 2014 9:55 PM, Kashish
wrote:
Hi,
I have a very weird problem. The wild card searc
And I closed the JIRA, see the comments. But the short form is that
it's not worth the effort because of the edge cases. Jack writes
up some of them; the short form is "what does stemming
do with terms like organiz* ". Sure, it would produce one token (which is
the main restriction on a MultiTermAw
Chiming in late here, just back from vacation. But off the top of my
head, I don't see any reason SnowballPorterFilterFactory shouldn't
be MultiTermAware.
I've created https://issues.apache.org/jira/browse/SOLR-3503 as
a placeholder.
Erick
On Fri, May 25, 2012 at 1:31 PM, wrote:
>> I don't kno
> I don't know the specific rules in these specific stemmers,
> but generally a
> "less aggressive" stemming (e.g., "plural-only") of
> "paintings" would be
> "painting", while a "more aggressive" stemming would be
> "paint". For some
> "aggressive" stemmers the stemmed word is not even a wor
ggressive" stemmers the stemmed word is not even a word.
It would be nice to have doc with some example words for each stemmer.
-- Jack Krupansky
-Original Message-
From: spr...@gmx.eu
Sent: Friday, May 25, 2012 5:59 AM
To: solr-user@lucene.apache.org
Subject: RE: Wildcard-Sear
012 03:25
> To: solr-user@lucene.apache.org
> Subject: Re: Wildcard-Search Solr 3.5.0
>
> I tried it and it does appear to be the
> SnowballPorterFilterFactory that
> normally does the accent folding but can't here because it is
> not multi-term
> aware. I did notic
k
version, and try to use GermanNormalizationFilterFactory, and that may be
good enough for your situation.
-- Jack Krupansky
-Original Message-
From: spr...@gmx.eu
Sent: Wednesday, May 23, 2012 10:16 AM
To: solr-user@lucene.apache.org
Subject: RE: Wildcard-Search Solr 3.5.0
I'd
> I'd guess that this is because SnowballPorterFilterFactory
> does not implement MultiTermAwareComponent. Not sure, though.
Yes, I think this hinders the automagically multiterm awarness to do it's
job.
Could an own analyzer chain with help? Like
described (very, very short, too short...) here:
I'd guess that this is because SnowballPorterFilterFactory does not implement
MultiTermAwareComponent. Not sure, though.
-Michael
> Maybe a filter like ISOLatin1AccentFilter that doesn't get
> applied when
> using wildcards? How do the terms actually appear in the index?
Bär get indexed as bar.
I use not ISOLatin1AccentFilter . My field def is this:
Maybe a filter like ISOLatin1AccentFilter that doesn't get applied when
using wildcards? How do the terms actually appear in the index?
Jens
On 05/23/2012 01:19 PM, spr...@gmx.eu wrote:
No one an idea?
Thx.
The text may contain "FooBar".
When I do a wildcard search like this: "Foo*" -
> -Original Message-
> From: Dmitry Kan [mailto:dmitry@gmail.com]
> Sent: Mittwoch, 23. Mai 2012 14:02
> To: solr-user@lucene.apache.org
> Subject: Re: Wildcard-Search Solr 3.5.0
>
> do umlauts arrive properly on the server side, no encoding
> issues?
Y
the umlauts but I have no idea what...
>
> > -Original Message-
> > From: Dmitry Kan [mailto:dmitry@gmail.com]
> > Sent: Mittwoch, 23. Mai 2012 13:36
> > To: solr-user@lucene.apache.org
> > Subject: Re: Wildcard-Search Solr 3.5.0
> >
> > wha
No. No hits for bä*.
It's something with the umlauts but I have no idea what...
> -Original Message-
> From: Dmitry Kan [mailto:dmitry@gmail.com]
> Sent: Mittwoch, 23. Mai 2012 13:36
> To: solr-user@lucene.apache.org
> Subject: Re: Wildcard-Search Solr 3.5.0
>
what about bä*->hits?
-- Dmitry
On Wed, May 23, 2012 at 2:19 PM, wrote:
> No one an idea?
>
> Thx.
>
>
> > > The text may contain "FooBar".
> > >
> > > When I do a wildcard search like this: "Foo*" - no hits.
> > > When I do a wildcard search like this: "foo*" - doc is
> > > found.
> >
> >
No one an idea?
Thx.
> > The text may contain "FooBar".
> >
> > When I do a wildcard search like this: "Foo*" - no hits.
> > When I do a wildcard search like this: "foo*" - doc is
> > found.
>
> Please see http://wiki.apache.org/solr/MultitermQueryAnalysis
Well, it works in 3.6. With one
> > The text may contain "FooBar".
> >
> > When I do a wildcard search like this: "Foo*" - no hits.
> > When I do a wildcard search like this: "foo*" - doc is
> > found.
>
> Please see http://wiki.apache.org/solr/MultitermQueryAnalysis
Well, it works in 3.6. With one exception: If I use german
> so your advice is to upgrade to 3.6?
Or, as a workaround, you can lowercase wildcard queries on the client side.
Hi Ahmet,
> Please see http://wiki.apache.org/solr/MultitermQueryAnalysis
so your advice is to upgrade to 3.6?
Thank you
> The text may contain "FooBar".
>
> When I do a wildcard search like this: "Foo*" - no hits.
> When I do a wildcard search like this: "foo*" - doc is
> found.
Please see http://wiki.apache.org/solr/MultitermQueryAnalysis
Celso
You are very welcome and yes I should have mentioned that wildcard searches are
not analyzed (which is a recurring theme). This also means that they are not
downcased, so the search TEST* will probably not find anything either in your
set up.
Cheers
François
On Jul 1, 2011, at 5:16 AM
Hi again,
read (past tense) TFM :-) and:
"On wildcard and fuzzy searches, no text analysis is performed on the
search word."
Thanks a lot François!
Regards,
Celso
On Fri, Jul 1, 2011 at 10:02 AM, Celso Pinto wrote:
> Hi François,
>
> it is indeed being stemmed, thanks a lot for the heads up.
Hi François,
it is indeed being stemmed, thanks a lot for the heads up. It appears
that stemming is also configured for the query so it should work just
the same, no?
Thanks again.
Regards,
Celso
2011/6/30 François Schiettecatte :
> I would run that word through the analyzer, I suspect that th
I would run that word through the analyzer, I suspect that the word 'teste' is
being stemmed to 'test' in the index, at least that is the first place I would
check.
François
On Jun 30, 2011, at 2:21 PM, Celso Pinto wrote:
> Hi everyone,
>
> I'm having some trouble figuring out why a query wit
Hi Ahmet,
>> so I created a fake license
>> ComplexPhrase-LICENSE-MIT.txt
>> for ComplexPhrase and tried again, which ran through
>> successfully, I hope this is OK.
>
> I didn't used it with solr 3.2. I will check about it.
>
> So your GOK field already contains the list as multivalued. Then y
> I tried to follow this recipe, adapting it to the solr 3.2
> I am testing right now.
> The first try gave me a message
>
> [java] !!! Couldn't get
> license file for
> /Installer/solr/apache-solr-3.2.0/solr/lib/ComplexPhrase-1.0.jar
> [java] At least one file does not
> have a lice
Hi Ahmet,
>>> I don't use it myself (but I will soon), so I
>>> may be wrong, but did you try
>>> to use the ComplexPhraseQueryParser :
>>>
>>> ComplexPhraseQueryParser
>>> QueryParser which
>>> permits complex phrase query syntax eg "(john
>>> jon jonathan~) peters*".
>>>
>>> It seem
> > I don't use it myself (but I will soon), so I
> may be wrong, but did you try
> > to use the ComplexPhraseQueryParser :
> >
> > ComplexPhraseQueryParser
> > QueryParser which
> permits complex phrase query syntax eg "(john
> > jon jonathan~) peters*".
> >
> > It seems that you coul
Hi Ludovic,
> I don't use it myself (but I will soon), so I may be wrong, but did you try
> to use the ComplexPhraseQueryParser :
>
> ComplexPhraseQueryParser
> QueryParser which permits complex phrase query syntax eg "(john
> jon jonathan~) peters*".
>
> It seems that you could do su
Hi Thomas,
I don't use it myself (but I will soon), so I may be wrong, but did you try
to use the ComplexPhraseQueryParser :
ComplexPhraseQueryParser
QueryParser which permits complex phrase query syntax eg "(john
jon jonathan~) peters*".
It seems that you could do such type of querie
Hmmm, have you tried EdgeNGrams? This works for me (at the expense
of a somewhat larger index, of course)...
and a field of type "edge" named "thomasfield"
Now searches like
thomasfield:"GOK IA 3"
(include quotes
Hi Erick,
I have a multivalued field "GOK" (local classification scheme) with separate
entries of the sort
IA 300; IC 330; IA 317; IA 318, i.e. 1 to 3 capital characters, space, 3
digits.
I want to be able to perform a truncated search on that field:
either just the string before the space, or
Yes there is, but you haven't provided enough information to
make a suggestion. What isthe fieldType definition? What is
the field definition?
Two resources that'll help you greatly are:
http://wiki.apache.org/solr/AnalyzersTokenizersTokenFilters
and the admin/analysis page...
Best
Erick
On Tue
Thanks, Ludovic. That was it. I added the word "conditional" to the
protected words file and I no longer see the odd search results when using
wildcards. I will try to disable stemming altogether.
Thanks again!
--
View this message in context:
http://lucene.472066.n3.nabble.com/wildcard-sea
And to be more helpfull, you can activate the debug (debugQuery=on in the
query) mode to see the transform query :
for instance 'field:contitional' :
field:conditional
field:conditional
field:condit
field:condit
for 'field:conditional*' :
field:conditional*
field:conditional*
field:conditional*
'conditional' seems to be stemmed into the word 'condit' in the index.
So your results are normal.
As you said, mixing wildcards searching and stemmed fields is not
recommanded.
Ludovic.
2011/4/1 Melanie Drake [via Lucene] <
ml-node+2763787-65059921-383...@n3.nabble.com>
> I noticed an inconsi
Bra1n,
Did you ever get this sorted out? I'm having the same problem, Unknown
query type "org.apache.lucene.search.WildcardQuery" found in phrase query
Thanks
--
View this message in context:
http://lucene.472066.n3.nabble.com/Wildcard-search-in-phrase-query-using-spanquery-tp729275p1568402.h
Thanks it worked now. I think building clean ant is what made the difference.
I'll work on this a bit more and give you feedbacks.
--
View this message in context:
http://n3.nabble.com/Wildcard-search-in-phrase-query-using-spanquery-tp729275p741988.html
Sent from the Solr - User mailing list arc
> I tried it by placing ComplexPhrase-1.0.jar in
> apache-solr-1.4.0\lib ;
> apache-solr-1.4.0\example\lib ; and
> apache-solr-1.4.0\example\solr\lib with
> the same error
You need to copy it to only apache-solr-1.4.0\lib
Maybe it is better to get a fresh copy of apache-solr-1.4.0.zip and contin
Ahmet Arslan wrote:
>
>
> Before calling 'ant dist' where did you copy the ComplexPhrase-1.0.jar?
>
> apache-solr-1.4.0\lib or apache-solr-1.4.0\example\lib?
>
>
>
I tried it by placing ComplexPhrase-1.0.jar in apache-solr-1.4.0\lib ;
apache-solr-1.4.0\example\lib ; and apache-solr-1.4.0\e
>
> I used command line to build ant this time.
>
Before calling 'ant dist' where did you copy the ComplexPhrase-1.0.jar?
apache-solr-1.4.0\lib or apache-solr-1.4.0\example\lib?
> Yes I ran solr using "java -jar start.jar". I did the above
> mentioned tasks
> but the results were the same.
I used command line to build ant this time.
Ahmet Arslan wrote:
>
>
> Are you running solr using "java -jar start.jar"?
> If yes you need to re-name
> apache-solr-1.4.0\dist\apache-solr-1.4.1-dev.war to solr.war and put it
> under apache-solr-1.4.0\example\webapps
>
> Also you may need to de
> I used eclipse-jee-galileo-SR2-win32 to build the ant and
> selected dist-war
> for execution in build. I got the following message.
I use command prompt to invoke ant so I am not sure about this.
> The solr performed as usual and when I tried adding
> &defType=complexphrase
> to search url th
I used eclipse-jee-galileo-SR2-win32 to build the ant and selected dist-war
for execution in build. I got the following message.
Buildfile: D:\apache-solr-1.4.0\build.xml
init-forrest-entities:
compile-solrj:
compile:
[javac] Compiling 1 source file to D:\apache-solr-1.4.0\build\solr
[jav
> I tried that and got the following result. Do I have to do
> anything other
> than the mentioned instructions to make it work?
>
> HTTP ERROR: 500
>
> tried to access field
> org.apache.lucene.queryParser.QueryParser.field from
> class
> org.apache.lucene.queryParser.ComplexPhraseQueryParser$C
I tried that and got the following result. Do I have to do anything other
than the mentioned instructions to make it work?
HTTP ERROR: 500
tried to access field org.apache.lucene.queryParser.QueryParser.field from
class
org.apache.lucene.queryParser.ComplexPhraseQueryParser$ComplexPhraseQuery
j
> I need to perform wildcard search in phrase query. I have 2
> documents
> containing text "how do impair" and "how to improve". I
> want to be able to
> search both documents by searching (how to im*). There is a
> provision in
> lucene which allows me to perform this operation using
> SpanWildca
hey thanks ravi , ahmed and Erik for your reply.
though its tough to change my solr version , still let me try out at 1.4
and see.
Erik Hatcher-4 wrote:
>
> Note that the query analyzer output is NOT doing query _parsing_, but
> rather taking the string you passed and running it through the
Note that the query analyzer output is NOT doing query _parsing_, but
rather taking the string you passed and running it through the query
analyzer only. When using the default query parser, Inte* will be a
search for terms that begin with "inte". It is odd that you're not
finding it. Bu
> Hi just looked at the analysis.jsp and found out what it
> does during index /
> query
>
> Index Analyzer
> Intel
> intel
> intel
> intel
> intel
> intel
If the resultant token is intel, then q=inte* should return documents.
What says when you add &debugQuery=on to your search url?
And w
Ashok:
May be this will help:
http://gravi2.blogspot.com/2009/05/solr-wildcards-and-omitnorms.html
~Ravi
On Tue, Jan 26, 2010 at 9:56 PM, ashokcz wrote:
>
> Hi just looked at the analysis.jsp and found out what it does during index
> /
> query
>
> Index Analyzer
> Intel
> intel
> inte
Hi just looked at the analysis.jsp and found out what it does during index /
query
Index Analyzer
Intel
intel
intel
intel
intel
intel
Query Analyzer
Inte*
Inte*
inte*
inte
inte
inte
int
I think somewhere my configuration or my definition of the type "text" is
wrong.
This is my conf
There are some approaches outlined here that might be of interest:
http://wiki.apache.org/solr/HierarchicalFaceting
On Jan 24, 2010, at 2:54 AM, Andy wrote:
I'd like to provide a hierarchical faceting functionality.
An example would be location drill down such as USA -> New Y
> Hi ,
> I m trying to use wildcard keywords in my search term and
> filter term . but
> i didnt get any results.
> Searched a lot but could not find any lead .
> Can someone help me in this.
> i m using solr 1.2.0 and have few records indexed with
> vendorName value as
> Intel
>
> In solr admin
Go through this thread first - http://markmail.org/message/bannl2fpblt5sqlw
If it still does not help, post back your field type definition in
schema.xml
Cheers
Avlesh
On Thu, Aug 6, 2009 at 3:46 PM, Radha C. wrote:
> Hi,
>
>
> I have documents contain word "healthcare articles". I need to matc
My *guess* is that what you're seeing is that wildcard searches are
not analyzed, in this case not run through the stemmer. So your
index only contains "system" and the funky variants (e.g. "systems/").
I don't really understand why you'd get "systems/" in your index, but
I'm assuming that your fil
Yes, thats correct. I have applied EnglishPorterFilterFactory at index time
as well. Do you think, I should remove it and do the indexing again.
Erick Erickson wrote:
>
> Are you by any chance stemming the field when you index?
>
> Erick
>
> On Fri, May 8, 2009 at 2:29 AM, dabboo wrote:
>
>
Are you by any chance stemming the field when you index?
Erick
On Fri, May 8, 2009 at 2:29 AM, dabboo wrote:
>
> Hi,
>
> I am facing a n wierd issue while searching.
>
> I am searching for word *sytem*, it displays all the records which contains
> system, systems etc. But when I tried to search
Hi Amit,
Leading wildcard searches are not allowing in Solr Out-of-the-box. There
are other techniques to overcome this handicap.
Search for "Leading Wildcards" in the user mailing list archives will
return the necessary mail threads which might be pretty useful to you.
-Kumar
-Original Mess
Hi Mahendra,
Wildcard searches are case-sensitive in Solr. I faced the same issue and
handled converting the query string to lower case in my code itself. The
filters and analyzers are not applicable for wildcard queries.
FYI
You will also face problem when you use keywords/Operators in your q
Norberto Meijome wrote:
ok well let's say that i can live without john/jon in the short term.
what i really need today is a case insensitive wildcard search with
literal matching (no fancy stemming. bobby is bobby, not bobbi.)
what are my options?
http://wiki.apache.org/solr/AnalyzersTokeniz
On Mon, 23 Jun 2008 14:23:14 -0700
Jon Drukman <[EMAIL PROTECTED]> wrote:
> ok well let's say that i can live without john/jon in the short term.
> what i really need today is a case insensitive wildcard search with
> literal matching (no fancy stemming. bobby is bobby, not bobbi.)
>
> what ar
Erik Hatcher wrote:
No, because the original data is Bobby Gaza, so
Bobby* would match, but not bobby*. "string" type (in the example
schema, to be clear) does effectively no analysis, leaving the original
string indexed as-is, case and all.
[...]
stemming and wildcard term queries aren't
On Jun 23, 2008, at 4:45 PM, Jon Drukman wrote:
Erik Hatcher wrote:
Jon,
You provided a lot of nice details, thanks for helping us help you :)
The one missing piece is the definition of the "text" field type.
In Solr's _example_ schema, "bobby" gets analyzed (stemmed) to
"bobbi"[1]. Whe
Erik Hatcher wrote:
Jon,
You provided a lot of nice details, thanks for helping us help you :)
The one missing piece is the definition of the "text" field type. In
Solr's _example_ schema, "bobby" gets analyzed (stemmed) to
"bobbi"[1]. When you query for bobby*, the query parser is not ru
1 - 100 of 104 matches
Mail list logo
