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 ,
>
Solr does not analyze queries with wildcards in it. So, with ch*p-seq,
it will search for terms that start with ch and end with p-seq. Since
your indexer has analyzed all tokens before, only chip and seq are in
the index.
See
https://solr.pl/en/2010/12/20/wildcard-queries-and-how-solr-handles-them
I am using edismax query parser.
On Fri, Dec 15, 2017 at 10:37 AM, Selvam Raman wrote:
> Solr version - 6.4.0
>
> "title_en":["Chip-seq"]
>
> When i fired query like below
>
> 1) chip-seq
> 2) chi*
>
> it is giving expected result, for this case one result.
>
> But when i am searching with wildc
It's the same in both cases:
enumerate all terms that start with "a" and collect them into
(conceptually) a huge OR query and execute it. There's been some work
lately to avoid the TooManyBooleanClauses exception, but it's still
the case that every term starting with "a" has to be examined and
eith
Hi,
You could try this:
drop wildcard stuff altogether:
1) Employ edgengramfilter at index time.
2) Use plain searches at query time.
Ahmet
On Friday, November 25, 2016 4:59 PM, Sandeep Khanzode
wrote:
Hi All,
Can someone please assist with this query?
My data consists of:
1.] John Doe
2.
Hi All,
Can someone please assist with this query?
My data consists of:
1.] John Doe
2.] John V. Doe
3.] Johnson Doe
4.] Johnson V. Doe
5.] John Smith
6.] Johnson V. Smith
7.] Matt Doe
8.] Matt V. Doe
9.] Matt Doe
10.] Matthew V. Doe
11.] Matthew Smith
12.] Matthew V. Smith
Querying ...
(a) Mat
Hi All, Erick,
Please suggest. Would like to use the ComplexPhraseQueryParser for searching
text (with wildcard) that may contain special characters.
For example ...John* should match John V. DoeJohn* should match Johnson
SmithBruce-Willis* should match Bruce-WillisV.* should match John V. F. Doe
Hi,
This is the typical TextField with ...
SRK
On Thursday, November 24, 2016 1:38 AM, Reth RM
wrote:
what is the fieldType of those records?
On Tue, Nov 22, 2016 at 4:18 AM, Sandeep Khanzode
wrote:
Hi Erick,
I gave this a try.
These are my results. Th
what is the fieldType of those records?
On Tue, Nov 22, 2016 at 4:18 AM, Sandeep Khanzode <
sandeep_khanz...@yahoo.com.invalid> wrote:
> Hi Erick,
> I gave this a try.
> These are my results. There is a record with "John D. Smith", and another
> named "John Doe".
>
> 1.] {!complexphrase inOrder=t
Hi Erick,
I gave this a try.
These are my results. There is a record with "John D. Smith", and another named
"John Doe".
1.] {!complexphrase inOrder=true}name:"John D.*" ... does not fetch any
results.
2.] {!complexphrase inOrder=true}name:"John D*" ... fetches both results.
Second observ
Thanks, Erick.
I am actually not trying to use the String field (prefer a TextField here).
But, in my comparisons with TextField, it seems that something like phrase
matching with whitespace and wildcard (like, 'my do*' or say, 'my dog*', or
say, 'my dog has*') can only be accomplished with a st
You have to query text and string fields differently, that's just the
way it works. The problem is getting the query string through the
parser as a _single_ token or as multiple tokens.
Let's say you have a string field with the "a b" example. You have a
single token
a b that starts at offset 0.
Hi Erick, Reth,
The 'a\ b*' as well as the q.op=AND approach worked (successfully) only for
StrField for me.
Any attempt at creating a 'a\ b*' for a TextField does not match any documents.
The parsedQuery in debug mode does show 'field:a b*'. I am sure there are
documents that should match.
An
You can escape the space with a backslash as 'a\ b*'
Best,
Erick
On Thu, Nov 10, 2016 at 2:37 PM, Reth RM wrote:
> I don't think you can do wildcard on StrField. For text field, if your
> query is "category:(test m*)" the parsed query will be "category:test OR
> category:m*"
> You can add q.o
I don't think you can do wildcard on StrField. For text field, if your
query is "category:(test m*)" the parsed query will be "category:test OR
category:m*"
You can add q.op=AND to make an AND between those terms.
For phrase type wild card query support, as per docs, it
is ComplexPhraseQueryPars
: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
Yes! wildcards are not analyzed. Thanks Shwan for reminding me.
Thanks Erick for your response.
Best,
Modassar
On Mon, Apr 18, 2016 at 8:53 PM, Erick Erickson
wrote:
> Here's a blog on the subject:
>
> https://lucidworks.com/blog/2011/11/29/whats-with-lowercasing-wildcard-multiterm-queries-in-s
Here's a blog on the subject:
https://lucidworks.com/blog/2011/11/29/whats-with-lowercasing-wildcard-multiterm-queries-in-solr/
bq: When validator is changed to validate, both at query time and index time,
then should not validator*/validator return the same results at-least?
This is one of those
On 4/18/2016 1:18 AM, Modassar Ather wrote:
> When I search for f:validator I get 80K+ documents whereas if I search for
> f:validator* I get only around 150 results.
>
> When I checked on analysis page I see that validator is changed to
> validate. Per my understanding in both the above cases it s
Thanks Reth for your response.
When validator is changed to validate, both at query time and index time,
then should not validator*/validator return the same results at-least?
E.g. 5 documents contains validator. At index time validator got changed to
validate.
Now when validator* is searched it
If you search for f:validat*, then I believe you will get same number of
results. Please check.
f:validator* is searching for records that have prefix "validator" where as
field with stemmer which stems "validator" to "validate" (if this stemming
was applied at index time as well as query time) it
You don't need to ngram at all if your queries themselves are going to be
wildcarded.
Erik
> On Dec 3, 2015, at 17:21, Kelly, Frank wrote:
>
> Hello Lucene Folks,
>
> Newbie here - I've found how Solr does Wildcard searches of the form
> field:a* using the EdgeNGramFilterFactor
Upayavira,
Thanks a lot for these information
Regards,
Bruno
Le 21/10/2015 19:24, Upayavira a écrit :
regexp will match the whole term. So, if you have stemming on, magnetic
may well stem to magnet, and that is the term against which the regexp
is executed.
If you want to do the regexp agains
regexp will match the whole term. So, if you have stemming on, magnetic
may well stem to magnet, and that is the term against which the regexp
is executed.
If you want to do the regexp against the whole field, then you need to
do it against a string version of that field.
The process of using a r
title:/magnet.?/ doesn't work for me because solr answers:
|title = "Magnetic folding system"|
but thanks to give me the idea to use regexp !!!
Le 21/10/2015 18:46, Upayavira a écrit :
No, you cannot tell Solr to handle wildcards differently. However, you
can use regular expressions for search
No, you cannot tell Solr to handle wildcards differently. However, you
can use regular expressions for searching:
title:/magnet.?/ should do it.
Upayavira
On Wed, Oct 21, 2015, at 11:35 AM, Bruno Mannina wrote:
> Dear Solr-user,
>
> I'm surprise to see in my SOLR 5.0 that the wildward ? replace
Sounds good. Thank you for the synonym (definitely will work on this) and
padding suggestions.
- Todd
--
View this message in context:
http://lucene.472066.n3.nabble.com/Wildcard-Regex-Searching-with-Decimal-Fields-tp4206015p4206421.html
Sent from the Solr - User mailing list archive at Nabble
Then it seems like you can just index the raw strings as a string
field and suggest with that but fire the actual query against the
numeric type.
Best,
Erick
On Tue, May 19, 2015 at 3:25 PM, Todd Long wrote:
> Erick Erickson wrote
>> But I _really_ have to go back to one of my original quest
Erick Erickson wrote
> But I _really_ have to go back to one of my original questions: What's
> the use-case?
The use-case is with autocompleting fields. The user might know a frequency
starts with 2 so we want to limit those results (e.g. 2, 23, 214, etc.). We
would still index/store the numeric-
No cleaner ways that spring to mind. Although you might get some
mileage out of normalizing
_everything_ rather than indexing different forms. Perhaps all numbers
are stored left-padded
with zeros to 16 places to the left of the decimal point and
right-padded 16 places to the right
of the decimal p
I see what you're saying and that should do the trick. I could index 123 with
an index synonym 123.0. Then my regex query "/123/" should hit along with a
boolean query "123.0 OR 123.00*". Is there a cleaner approach to breaking
apart the boolean query in this case? Right now, outside of Solr, I'm j
I really have in mind an index-time filter, not necessarily a
query-time Filter. So at index time you have something like 123.4000.
You index synonyms 123.4 and 123 (or whatever) and now your _queries_
should "just work" since the forms you need are in the index already
and whether it's a regex or
Erick Erickson wrote
> No, not using SynonymFilterFactory. Rather take that as a base for a
> custom Filter that
> doesn't use any input file.
OK, I just wanted to make sure I wasn't missing something that could be done
with the SynonymFilterFactory itself. At one time, I started going down this
p
No, not using SynonymFilterFactory. Rather take that as a base for a
custom Filter that
doesn't use any input file. Rather it would normalize any numeric
tokens and inject
as many variants on the spot as you desire.
Best,
Erick
On Mon, May 18, 2015 at 9:56 AM, Todd Long wrote:
> Essentially, we
Essentially, we have a grid of data (i.e. frequencies, baud rates, data
rates, etc.) and we allow wildcard filtering on the various columns. As the
user provides input, in a specific column, we simply filter the overall data
by an implicit "starts with" query (i.e. 23 becomes 23*). In most cases,
y
This feels like an XY problem. Either you're working with numbers or
you're not. It's hard for me to imagine what purpose is served by a
query on numerical data that would match 2.5, 20.5, 299.5,
299.5 etc, much less regexes. That may just be my limited
imagination however.
You could s
Maybe you should first disclose the nature of the business problem you are
trying to solve.
To be clear, patterns and wildcards are string processing operations, not
numeric operations. Usually one searches for ranges of numeric values. So,
again, what operation are you really trying to perform th
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.
This may have been introduced by changes made to solve
https://issues.apache.org/jira/browse/SOLR-5968
I created https://issues.apache.org/jira/browse/SOLR-6501 to track the new
bug.
On Tue, Sep 9, 2014 at 4:53 PM, Mike Hugo wrote:
> Hello,
>
> With Solr 4.7 we had some queries that return dyna
What you are asking for is comparable to saying:
In my index I have a TrieIntField called severity when i search for
severity:8765432 I get results, but when i search for severity:8* i get no
results -- what do i need to change so that this type of query matches
8765432 and 8978 and 84356 etc.
cases, but my personal
imagination is not at issue for this particular thread.
-- Jack Krupansky
-Original Message-
From: Shawn Heisey
Sent: Thursday, May 29, 2014 9:46 AM
To: solr-user@lucene.apache.org
Subject: Re: wildcard matches in EnumField - what do I need to change in
code to
At a minimum, the doc is too skimpy to say whether this should work or
whether this is forbidden. That said, I wouldn't have expected wildcard to
be supported for enum fields since they are really storing small integers.
Ditto for regular expressions on enum fields.
See:
https://cwiki.apache.o
On 5/29/2014 12:50 AM, Elran Dvir wrote:
> In my index, I have an EnumField called severity. This is its configuration
> in enumsConfig.xml:
>
>
> Not Available
> Low
>Medium
>High
>Critical
>
>
> My index contains documents with these values.
> When I se
I mark all the filters that support wildcards with (multi) on my list:
http://www.solr-start.com/info/analyzers/ . I uses actual interface
markers to derive that list, so it should be most up to date.
Regards,
Alex.
Personal website: http://www.outerthoughts.com/
Current project: http://www.sol
On 5/5/2014 5:19 AM, Jack Krupansky wrote:
> But, you stay that you are using the stemmer to remove diacritical
> marks... you can/should use ASCIIFoldingFilterFactory or
> MappingCharFilterFactory.
I like ICUFoldingFilterFactory for this, but it does require additional
contrib jars (included in t
SOLVED!
First solution I tried (the Ahmet's one) worked fine!
Thank you!
-Mensaje original-
De: Jack Krupansky [mailto:j...@basetechnology.com]
Enviado el: lunes, 05 de mayo de 2014 13:19
Para: solr-user@lucene.apache.org; rgonza...@normagricola.com
Asunto: Re: Wildcard malfuncti
Generally, stemming filters are not supported when wildcards are present.
Only a small subset of filters work with wildcards, such as the case
conversion filters.
But, you stay that you are using the stemmer to remove diacritical marks...
you can/should use ASCIIFoldingFilterFactory or Mapping
Hi Roman,
What you are experiencing is a OK and known. Stemming and wildcard searches
could be counter intuitive sometimes. But luckily remedy is available. Use the
following filters, and your wildcard searches will be happy. Please not that
this change will require solr-restart and re-index.
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
No. Field is of type "text_en". I can use "text_en_splitting_edge_ngram"
for now. Its working for me. But it puts so much load on solr i think as
all ngrams will have to be indexed. Thats why I was looking for a solution
with wildcard.
On Wed, Mar 26, 2014 at 11:20 PM, Erick Erickson [via Lucene]
Looks like maybe you're defining the field is a string type?
On Mar 26, 2014 9:07 AM, "pratpor" wrote:
> I am having some strange issue with solr that I found nowhere on the web. I
> was looking for partial matches for some fields in solr. I know of the "*"
> wildcard which can be used for the sa
Hi Pratpor,
With recently added (to trunk) complex phrase query parser ( SOLR-1604 ) it is
possible to use : "Some va*" types of queries. But you need to use solr-trunk
for this. Or you need to wait solr 4.8
Ahmet
On Wednesday, March 26, 2014 3:14 PM, pratpor wrote:
I am having some strange
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
Hoh, I can see that when there are wildcards then KeywordTokenizerFactory is
used instead of StandardTokenizerFactory.
I created custom wildcard remover char filter for few specific cases (so I
cannot use any of regex replacer filters) but event with that,
KeywordTokenizerFactory is used.
I though
It works! Thanks.
Last question: how to invoke charFilter before tokenizer? I can see that
with tokenizer StandardTokenizerFactory without wildcards text "123-abc" is
broken into two tokens "123" and "abc" but text "*123-abc*" remain unchanged
"*123-abc*".
It is possible to use charFilter before
Hi,
Yes some factories implement
org.apache.lucene.analysis.util.MultiTermAwareComponent
Please see more http://wiki.apache.org/solr/MultitermQueryAnalysis
On Wednesday, December 18, 2013 1:05 PM, michallos
wrote:
Hello,
I have a problem with configuring custom char filter. When there are
Thank you Jack, I've totally missed this type of plug-in.
Artem.
25.07.2013 23:38, Jack Krupansky пишет:
Yeah, those are the rules. They are more of a heuristic that manages to work
most of the time reasonably well, but like most heuristics, it is not
perfect.
In this particular case, your bes
Yeah, those are the rules. They are more of a heuristic that manages to work
most of the time reasonably well, but like most heuristics, it is not
perfect.
In this particular case, your best bet would be to use an update processor
to discard the "ignored" field values before Solr actually sees
I am testing it.. and i will upload it after that..
./Zahoor
HBase Musings
On 09-Jan-2013, at 2:55 AM, Upayavira wrote:
> Have you uploaded a patch to JIRA???
>
> Upayavira
>
> On Tue, Jan 8, 2013, at 07:57 PM, jmozah wrote:
>> Hmm. Fixed it.
>>
>> Did similar thing as SOLR-247 for distrib
Have you uploaded a patch to JIRA???
Upayavira
On Tue, Jan 8, 2013, at 07:57 PM, jmozah wrote:
> Hmm. Fixed it.
>
> Did similar thing as SOLR-247 for distributed search.
> Basically modified the FacetInfo method of the FacetComponent.java to
> make it work.. :-)
>
> ./zahoor
>
>
> On 08-Jan-2
Hmm. Fixed it.
Did similar thing as SOLR-247 for distributed search.
Basically modified the FacetInfo method of the FacetComponent.java to make it
work.. :-)
./zahoor
On 08-Jan-2013, at 9:35 PM, jmozah wrote:
>
> I can try to bump it for distributed search...
> Some pointer where to start
I can try to bump it for distributed search...
Some pointer where to start will be helpful...
Can SOLR-2894 be a good start to look at this?
./Zahoor
On 08-Jan-2013, at 9:27 PM, Michael Ryan wrote:
> I'd guess that the patch simply doesn't implement it for distributed
> searches. The code fo
I'd guess that the patch simply doesn't implement it for distributed searches.
The code for distributed facets is quite a bit more complicated, and I don't
see it touched in this patch.
-Michael
-Original Message-
From: jmozah [mailto:jmo...@gmail.com]
Sent: Tuesday, January 08, 2013 1
Yeah, it's fully integrated into 4.0.
There is a patch here that may or may not work with 3.6:
https://issues.apache.org/jira/browse/SOLR-2703
-- Jack Krupansky
-Original Message-
From: Bruno Mannina
Sent: Monday, December 17, 2012 9:31 AM
To: solr-user@lucene.apache.org
Subjec
Both method doesn't work on my Solr 3.6, with the error message:
_Unknown query type 'surround'_
Le 17/12/2012 15:18, Jack Krupansky a écrit :
Not with the standard query parsers, but you can do it with the
"surround" query parser:
defType=surround&q=title:(plast* w bicycle)
Or
q={!surro
Not with the standard query parsers, but you can do it with the "surround"
query parser:
defType=surround&q=title:(plast* w bicycle)
Or
q={!surround}title:(plast* w bicycle)
Two notes:
1. Surround performs NO analysis, so you have to manually analyze your
terms, like lower case them if neces
Le 17/12/2012 14:13, Ahmet Arslan a écrit :
Wildcard seems not to work inside double quote request.
I get always 0 result.
I.e:
title:"plastic bicycle" <== 79 results in my database
title:"plast* bicycle" <== 0 result found
Is exist a solution for that ?
Hi Bruno,
You can make use of https:/
> Wildcard seems not to work inside double quote request.
> I get always 0 result.
>
> I.e:
> title:"plastic bicycle" <== 79 results in my database
> title:"plast* bicycle" <== 0 result found
>
> Is exist a solution for that ?
Hi Bruno,
You can make use of https://issues.apache.org/jira/browse
Thanks, Erick. That really helped us in learning about tokens and how the
Analyzer works. Thank you!
Warm regards,
Alex
-Original Message-
From: Erick Erickson [mailto:erickerick...@gmail.com]
Sent: 19 September 2012 3:56 PM
To: solr-user@lucene.apache.org
Subject: Re: Wildcard
1 - 100 of 292 matches
Mail list logo
