Re: Multiword synonyms and term wildcards/substring matching

e been trying to implement multi word synonyms using `sow=false` > into > > a pre-existing system that applied pre-processing to the phrase to apply > > wildcards around the terms, i.e. `bread stick` => `*bread* *stick*`. > > > > I got the synonyms expansion working pe

Re: Multiword synonyms and term wildcards/substring matching

ssing to the phrase to apply > wildcards around the terms, i.e. `bread stick` => `*bread* *stick*`. > > I got the synonyms expansion working perfectly, after discovering the > `preserveOriginal` filter param, but then I needed to re-implement the > existing wildcard behaviour. > I

Multiword synonyms and term wildcards/substring matching

Hi All I have been trying to implement multi word synonyms using `sow=false` into a pre-existing system that applied pre-processing to the phrase to apply wildcards around the terms, i.e. `bread stick` => `*bread* *stick*`. I got the synonyms expansion working perfectly, after discovering

Re: Prefix + Suffix Wildcards in Searches

That’s not quite the question I was asking. Let’s take "…that don’t contain the characters ‘paid’ “. Start with the fact that no matter what the mechanics of implementing pre-and-post wildcards, something like *:* -tags:*paid* would exclude a doc with a tag of "credit-ms-reply-unpa

Re: Prefix + Suffix Wildcards in Searches

The obvious suggestion would be to have the users just use the entire tag > (i.e. don't let them do a "contains") as a condition to eliminate the > wildcards - which would work - but unfortunately we have customers with (*not > joking*) over 100K different tags (*why have a t

Re: Prefix + Suffix Wildcards in Searches

y-unpaid", but do include documents tagged with the characters "ms-reply-paid". The obvious suggestion would be to have the users just use the entire tag (i.e. don't let them do a "contains") as a condition to eliminate the wildcards - which would work - but unfortunate

Re: Prefix + Suffix Wildcards in Searches

Hello, Chris. I suppose index time analysis can yield these terms: "paid","ms-reply-unpaid","ms-reply-paid", and thus let you avoid these expensive wildcard queries. Here's why it's worth to avoid them https://www.slideshare.net/lucidworks/search-like-sql-mikhail-khludnev-epam On Mon, Jun 29, 2020

Re: Prefix + Suffix Wildcards in Searches

mean. So let’s get some use-cases in place. Can users enter tags like blahms-reply-unpaidnonsense and expect to find it with *ms-reply-unpaid*? Or is the entry something like my dog has ms-reply-unpaid and is mangy ? If the latter, simple token searching will work fine, there’s no need for wildcards

Re: Prefix + Suffix Wildcards in Searches

dex “paid”, “ms-reply-unpaid” etc? Then there > are no wildcards at all. This akin to “concept search”. > > Otherwise ngramming is your best bet. > > What’s the field type anyway? Is this field tokenized? > > There are lots of options, but s much depends on whether > yo

Re: Prefix + Suffix Wildcards in Searches

How regular are your patterns? Are they arbitrary? What I’m wondering is if you could shift your work the the indexing end, perhaps even in an auxiliary field. Could you, say, just index “paid”, “ms-reply-unpaid” etc? Then there are no wildcards at all. This akin to “concept search”. Otherwise

Prefix + Suffix Wildcards in Searches

Hello, all! I'm relatively new to Solr and Lucene (*using Solr 7.7.1*) but I'm looking into options for optimizing something like this: > fq=(tag:* -tag:*paid*) OR (tag:* -tag:*ms-reply-unpaid*) OR tag:*ms-reply-paid* It's probably not a surprise that we're seeing performance issues with somethin

Re: wildcards match end-of-word?

Remove the stopword and stemmer filters from your schema and reindex. Removing stopwords means you can never match “vitamin a”. Stemming interferes with wildcard matches. Either stem or do wildcards on a field, not both. Also, what do your users expect to get with wildcard matches? Those are a

Re: [External] wildcards match end-of-word?

tps://docs.google.com/presentation/d/10fIAesqkTnvmJBFaerEhnqWhSiaEvVW7u9jE1nX564Q/edit?usp=sharing > > thanks, > steve > > -Original Message- > From: Sotiris Fragkiskos > Sent: Thursday, February 13, 2020 4:03 AM > To: solr-user@lucene.apache.org > Subject: [Ext

RE: [External] Re: wildcards match end-of-word?

@lucene.apache.org Subject: RE: [External] Re: wildcards match end-of-word? Folks, I am seeing very strange (bad) wildcard behavior (solr 8). "kinase" finds hits as expected. "kin*ase" and "kin*se" find 0 results. "kinase*" matches only values like &qu

Re: [External] Re: wildcards match end-of-word?

Hi, I could be wrong, but I'm starting to think that it has to do with the fieldType. In our case, wildcards don't seem to work at all with text_en types, but they do work with string types. On Thu, Feb 13, 2020 at 1:52 PM Fischer, Stephen < sfisc...@pennmedicine.upenn.edu> wrote:

RE: [External] Re: wildcards match end-of-word?

chema for the fieldType in question https://docs.google.com/presentation/d/10fIAesqkTnvmJBFaerEhnqWhSiaEvVW7u9jE1nX564Q/edit?usp=sharing thanks, steve -Original Message- From: Sotiris Fragkiskos Sent: Thursday, February 13, 2020 4:03 AM To: solr-user@lucene.apache.org Subject: [Exte

Re: wildcards match end-of-word?

kinase to the query, that token is stemmed to > “kinas” and matches. > > Also, adding &debug=query to your URL will show you what the query looks > like after parsing and analysis, also a major tool for figuring out what’s > really happening. > > Wildcards are not stemmed, which c

Re: wildcards match end-of-word?

uery looks like after parsing and analysis, also a major tool for figuring out what’s really happening. Wildcards are not stemmed, which can lead to surprising results. There’s no perfect answer here. Let’s claim wildcards _were_ stemmed. Then you’d have to try to explain why “running*” returned a

RE: [External] Re: wildcards match end-of-word?

"query":{ "time":0.0}, "facet":{ "time":0.0}, "facet_module":{ "time":0.0}, "mlt":{ "time":0.0}, "highlight":{ "time":

Re: wildcards match end-of-word?

y the solution would be > for them (actually us, on their behalf), to use kinase* OR kinase. > > But that is kind of a hack. > > Is there a way we can configure solr to have wildcards match on end-of-word? > > Thanks, > Steve

wildcards match end-of-word?

kinase* will not match the word "kinase". Our end-users won't expect this behavior. Presumably the solution would be for them (actually us, on their behalf), to use kinase* OR kinase. But that is kind of a hack. Is there a way we can configure solr to have wildcards match on end-of-word? Thanks, Steve

Problems with StemFilter and Wildcards

Hi, we have got some problems with the stemming of our ocr-texts: We use the following configuration for our full-text-ocr field: Now it seems, the StemFilter and wildcard queries don't work together. When I search for

Re: Matching Queries with Wildcards and Numbers

I think it should have worked. Could you share the results for both queries with &debug=true? Also, what's the result for ec1? -- Sent from: http://lucene.472066.n3.nabble.com/Solr-User-f472068.html

Re: Matching Queries with Wildcards and Numbers

Hi tapan, please check below. *Conf:-* *Check attached image for issue:-* When i search with *ec* results are

Re: Matching Queries with Wildcards and Numbers

Hello Rakesh, As pointed out by Erick, changing *catenateAll* from 0 to 1 should work. What this means is that, generateWordParts="1" generates tokens for words for e.g. in the case of i-pad, it generates i, pad and ipad.and generateNumberParts="1" generates tokens for numbers for e.g in the case

Re: Matching Queries with Wildcards and Numbers

Do you find any solution for above issue ? -- Sent from: http://lucene.472066.n3.nabble.com/Solr-User-f472068.html

Re: Matching Queries with Wildcards and Numbers

Hi, Do you find any solution for above issue? Br, Rakesh -- Sent from: http://lucene.472066.n3.nabble.com/Solr-User-f472068.html

Re: Multiple consecutive wildcards (**) causes Out-of-memory

Just to clarify: I can only cause this to happen when using the complexphrase query parser. Lucene/dismax/edismax parsers are not affected. 2018-02-07 13:09 GMT+01:00 Bjarke Buur Mortensen : > Hello list, > > Whenever I make a query for ** (two consecutive wildcards) it causes my >

Multiple consecutive wildcards (**) causes Out-of-memory

Hello list, Whenever I make a query for ** (two consecutive wildcards) it causes my Solr to run out of memory. http://localhost:8983/solr/select?q=** Why is that? I realize that this is not a reasonable query to make, but the system supports input from users, and they might by accident input

RE: Complexphrase treats wildcards differently than other query parsers

SOLR-11450 and attached a unit test based on your correction of mine. 😊 Thank you, again! -Original Message- From: Bjarke Buur Mortensen [mailto:morten...@eluence.com] Sent: Monday, October 9, 2017 8:39 AM To: solr-user@lucene.apache.org Subject: Re: Complexphrase treats wildcards differ

Re: Complexphrase treats wildcards differently than other query parsers

ame='id']='1']" > ); > > assertQ(req("q", "{!complexphrase} iso-latin1:\"caezy~1 traen\"") > , "//result[@numFound='1']" > , "//doc[./str[@name='id']='1']" >

RE: Complexphrase treats wildcards differently than other query parsers

]='1']" ); assertQ(req("q", "{!complexphrase} iso-latin1:\"craez* traen\"") , "//result[@numFound='1']" , "//doc[./str[@name='id']='1']" ); assertQ(req("q", "

Re: Complexphrase treats wildcards differently than other query parsers

Thanks a lot for your effort, Tim. Looking at it from the Solr side, I see some use of local classes. The snippet below in particular caught my eye (in solr/core/src/java/org/apache/solr/search/ComplexPhraseQParserPlugin.java). The instance of ComplexPhraseQueryParser is not the clean one from Luc

RE: Complexphrase treats wildcards differently than other query parsers

After some more digging, I'm wrong even at the Lucene level. When I use the CustomAnalyzer and make my UC vowel mock filter MultitermAware, I get this with Lucene in trunk: "the* quick~" name:thE* name:qUIck~2 name:thE name:qUIck So, there's room for improvement with phrases, but the regular mu

RE: Complexphrase treats wildcards differently than other query parsers

ssage- From: Bjarke Buur Mortensen [mailto:morten...@eluence.com] Sent: Thursday, October 5, 2017 8:52 AM To: solr-user@lucene.apache.org Subject: Re: Complexphrase treats wildcards differently than other query parsers Thanks Tim, that might be what I'm experiencing. I'm actually quit

Re: Complexphrase treats wildcards differently than other query parsers

name:thE name:qUIck > > > [1] https://github.com/tballison/lucene-addons/blob/master/ > lucene-5205/src/test/java/org/apache/lucene/queryparser/ > spans/TestAdvancedAnalyzers.java#L117 > > -Original Message- > From: Allison, Timothy B. [mailto:talli...@mitre.org] > S

RE: Complexphrase treats wildcards differently than other query parsers

lob/master/lucene-5205/src/test/java/org/apache/lucene/queryparser/spans/TestAdvancedAnalyzers.java#L117 -Original Message- From: Allison, Timothy B. [mailto:talli...@mitre.org] Sent: Thursday, October 5, 2017 8:02 AM To: solr-user@lucene.apache.org Subject: RE: Complexphrase treats wildca

RE: Complexphrase treats wildcards differently than other query parsers

-user@lucene.apache.org Subject: Re: Complexphrase treats wildcards differently than other query parsers 2017-10-05 11:29 GMT+02:00 Emir Arnautović : > Hi Bjarke, > You are right - I jumped into wrong/old conclusion as the simplest > answer to your question. No problem :-) I guess

Re: Complexphrase treats wildcards differently than other query parsers

> > Well, according to > > https://lucidworks.com/2011/11/29/whats-with-lowercasing- > wildcard-multiterm-queries-in-solr/ > > multiterm means > > > > wildcard > > range > > prefix > > > > so it is that way i'm using the word

Re: Complexphrase treats wildcards differently than other query parsers

i'm using the word. That same article explains how > analysis will be performed with wildcards if the analyzers are multi-term > aware. > Furthermore, both lucene and dismax do the correct analysis, so I don't > think you are right in your statement about the majority of QPs skipp

Re: Complexphrase treats wildcards differently than other query parsers

Well, according to https://lucidworks.com/2011/11/29/whats-with-lowercasing-wildcard-multiterm-queries-in-solr/ multiterm means wildcard range prefix so it is that way i'm using the word. That same article explains how analysis will be performed with wildcards if the analyzers are multi

Re: Complexphrase treats wildcards differently than other query parsers

Hi Bjarke, It is not multiterm that is causing query parser to skip analysis chain but wildcard. The majority of query parsers do not analyse query string if there are wildcards. HTH Emir -- Monitoring - Log Management - Alerting - Anomaly Detection Solr & Elasticsearch Consulting Sup

Complexphrase treats wildcards differently than other query parsers

Hi list, I'm trying to search for the term funktionsnedsättning* In my analyzer chain I use a MappingCharFilterFactory to change ä to a. So I would expect that funktionsnedsättning* would translate to funktionsnedsattning*. If I use e.g. the lucene query parser, this is indeed what happens: ...de

Re: WordDelimiterFilterFactory with Wildcards

bq: To me this seems like a design flaw. The Solr fieldtypes seem like they allow a developer to create types that should handle wildcards intelligently. Well, that's pretty impossible. WordDelimiter(Graph)FilterFactory is a case in point. It's designed to break up on uppercase/lowerca

Re: WordDelimiterFilterFactory with Wildcards

ded special characters > > will bypass > > normal analysis - you need to enter the term exactly as it would be > > analyzed > > at index time for wildcard to work." > > > > To me this seems like a design flaw. The Solr fieldtypes seem like they > > allow

Re: WordDelimiterFilterFactory with Wildcards

quot;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 > analyzed > at index time for wildcard to work." > > To me this seems like a design flaw. The Solr fieldtypes seem like

Re: WordDelimiterFilterFactory with Wildcards

es seem like they allow a developer to create types that should handle wildcards intelligently. At the very least the Analyzer tool should show this behavior, and not even try to analyze terms with wildcards. Actually the behavior would more correctly be stated as "You need to enter the term exact

Re: WordDelimiterFilterFactory with Wildcards

The Admin/Analysis page is useful here. It'll show you what each bit of your query analysis chain does and may well point you to the part of the chain that's the problem. Best, Erick On Wed, Jul 26, 2017 at 11:33 AM, Webster Homer wrote: > checked the Pattern Replace it's OK. Can't use the prese

Re: WordDelimiterFilterFactory with Wildcards

checked the Pattern Replace it's OK. Can't use the preserve original since it preserves the hyphens too, which I don't want. It would be best if it didn't touch the * at all On Wed, Jul 26, 2017 at 1:30 PM, Saurabh Sethi wrote: > My guess is PatternReplaceFilterFactory is most likely the cause.

Re: WordDelimiterFilterFactory with Wildcards

My guess is PatternReplaceFilterFactory is most likely the cause. Also, based on your query, you might want to set preserveOriginal=1 You can take one filter out at a time and see which one is altering the query. On Wed, Jul 26, 2017 at 11:13 AM, Webster Homer wrote: > 1. KeywordTokenizer - we

Re: WordDelimiterFilterFactory with Wildcards

1. KeywordTokenizer - we want to treat the entire field as a single term to parse 2. preserveOriginal = "0" Thought about changing this to 1 3. 6.2.2 This is the fieldtype

Re: WordDelimiterFilterFactory with Wildcards

1. What tokenizer are you using? 2. Do you have preserveOriginal="1" flag set in your filter? 3. Which version of solr are you using? On Wed, Jul 26, 2017 at 10:48 AM, Webster Homer wrote: > I have several fieldtypes that use the WordDelimiterFilterFactory > > We have a fieldtype for cas numbers

WordDelimiterFilterFactory with Wildcards

I have several fieldtypes that use the WordDelimiterFilterFactory We have a fieldtype for cas numbers. which look like 1234-12-1, numbers separated by hyphens, users often leave out the hyphens and either use spaces or just string the numbers together. The WDF seemed like a great solution especia

Re: XMLQueryParser support for Wildcards and Prefix Queries

Hello, As far as I understand you can hookup lucene syntax with . On Mon, Feb 6, 2017 at 2:18 PM, Puneet Pawaia wrote: > Hi, > > I see that the Lucene XMLQueryParser still does not support some query > types like Wildcard queries and Prefix queries. > How is the search for terms

XMLQueryParser support for Wildcards and Prefix Queries

Hi, I see that the Lucene XMLQueryParser still does not support some query types like Wildcard queries and Prefix queries. How is the search for terms with wildcards etc proposed to be handled by XmlQueryParser? Thanks. Puneet

Re: Matching Queries with Wildcards and Numbers

obably can get what you want by changing the index time definition of WDFF from catenateAll="0" to catenateAll="1". That will put Sidem, 2, and Sidem2 in your index. Then the fact that query time processing for wildcards does _not_ break things up, Sidem2 will go through at qu

Matching Queries with Wildcards and Numbers

Hi! I am a Solr user having an issue with matches on searches using the wildcard operators, specifically when the searches include a wildcard operator with a number. Here is an example. My query will look like (productTitle:*Sidem2*) and match nothing, when it should be matching the productTitle Si

Re: Search multiple values with wildcards

Hi Jack, Ahmet, Thanks for your tips! In the end I found this the best way to do it: q=proprietaryMessage_tis:(25++23456*++32A++130202US*) All the best -- View this message in context: http://lucene.472066.n3.nabble.com/Search-multiple-values-with-wildcards-tp4161916p4163263.html Sent

Re: Search multiple values with wildcards

2014 6:08 PM, J'roo wrote: Hi, I am using Solr 3.5.0 with JavaClient SolrJ which I cannot change. I have following type of docs: :20:13-900-C05-P001:21:REF12349:25:23456789:32A:130202USD100,00:52A:/123456 I want to be able to find docs containing :25:234* AND :32A:1302* using wildcards

Re: Search multiple values with wildcards

14 11:08 AM To: solr-user@lucene.apache.org Subject: Search multiple values with wildcards Hi, I am using Solr 3.5.0 with JavaClient SolrJ which I cannot change. I have following type of docs: :20:13-900-C05-P001:21:REF12349:25:23456789:32A:130202USD100,00:52A:/123456 I want to be able to find doc

complexphrase with wildcards

https://gist.github.com/kindkid/c9f0ed9ee417064c1245 I'm using Solr 4.10.0, and getting a couple of error messages for invalid complexphrase queries that I don't understand. Are these known bugs or am I just doing something wrong? Relevant portion of schema.xml...

Search multiple values with wildcards

Hi, I am using Solr 3.5.0 with JavaClient SolrJ which I cannot change. I have following type of docs: :20:13-900-C05-P001:21:REF12349:25:23456789:32A:130202USD100,00:52A:/123456 I want to be able to find docs containing :25:234* AND :32A:1302* using wildcards, which I thought to do like: &a

Re: Wildcards and Phrase queries

ention yet.  Ahmet From: Isaac Hebsh To: solr-user@lucene.apache.org Sent: Monday, June 24, 2013 12:25 AM Subject: Re: Wildcards and Phrase queries Ahmet, it looks great! Can you tell us why havn't this code been commited into lucene+solr trunk? On Su

Re: Wildcards and Phrase queries

r@lucene.apache.org > Sent: Saturday, June 22, 2013 9:33 PM > Subject: Re: Wildcards and Phrase queries > > > Thanks Erick. > Maybe lucene (java-user) is a better mailing list to ask in? > > > On Sat, Jun 22, 2013 at 7:30 AM, Erick Erickson >wrote: > > > Wou

Re: Wildcards and Phrase queries

From: Isaac Hebsh To: solr-user@lucene.apache.org Sent: Saturday, June 22, 2013 9:33 PM Subject: Re: Wildcards and Phrase queries Thanks Erick. Maybe lucene (java-user) is a better mailing list to ask in? On Sat, Jun 22, 2013 at 7:30 AM, Erick Erickson wrote

Re: Wildcards and Phrase queries

terms of whether you wanted > to use these for production. > > I confess I don't know what state they were left in or why they were > never committed. > > FWIW, > Erick > > On Wed, Jun 19, 2013 at 10:08 AM, Isaac Hebsh > wrote: > > Hi, > > > >

Re: Wildcards and Phrase queries

W, Erick On Wed, Jun 19, 2013 at 10:08 AM, Isaac Hebsh wrote: > Hi, > > I'm trying to understand what is the status of enabling wildcards on phrase > queries? > > Lucene JIRA issue: https://issues.apache.org/jira/browse/LUCENE-1486 > Solr JIRA issue: https://issues.apache.

Wildcards and Phrase queries

Hi, I'm trying to understand what is the status of enabling wildcards on phrase queries? Lucene JIRA issue: https://issues.apache.org/jira/browse/LUCENE-1486 Solr JIRA issue: https://issues.apache.org/jira/browse/SOLR-1604 It looks like these issues are not going to be solved in the

Re: High QTime when wildcards in hl.fl are used

I've found more interesting informations about using fastVectorHighlighting combined with highlighted fields with wildcards after testing on isolated group of documents with text content. fvh + fulltext_*: QTime ~4s (!) fvh + fulltext_1234: QTime ~50ms no fvh + fulltext_*: QTime ~600ms n

Re: Wildcards and fuzzy/phonetic query

Thank you! I actually tried to look through Jira, but I didn't focus on the minor issues. For me, this is quite critical.. :-) Any chance of merging this into the 4.0.1 release? Regards, Haagen Den 11. des. 2012 kl. 12:45 skrev Ahmet Arslan: >> Lowercasing actually seems to work with Wildc

Re: Wildcards and fuzzy/phonetic query

> Lowercasing actually seems to work with Wildcard queries, > but not with fuzzy queries.  Are there any reasons why > I should experience such a difference? Hi Haagen, Yonik added this recently. https://issues.apache.org/jira/browse/SOLR-4076

Re: Wildcards and fuzzy/phonetic query

Lowercasing actually seems to work with Wildcard queries, but not with fuzzy queries. Are there any reasons why I should experience such a difference? Regards, Haagen Den 10. des. 2012 kl. 13:24 skrev Haagen Hasle: > > It's been two months since I asked about wildcards a

Re: Wildcards and fuzzy/phonetic query

It's been two months since I asked about wildcards and phonetic filters, and finally the task of upgrading Solr to version 4.0 was prioritized in our project. So the last couple of days I've been working on it. Another team member upgraded Solr from 3.4 to 4.0, and I've been

RE: Synomyns.txt not working with wildcards in query

Hi Query's with wildcards or fuzzy operators are called multi term queries and do not pass through the field's analyzer as you might expect. See: http://wiki.apache.org/solr/MultitermQueryAnalysis -Original message- > From:Pratyul Kapoor > Sent: Thu 06-Dec-2012

Re: Wildcards and fuzzy/phonetic query

It won't crash Solr if you include it, but it probably won't do what you expect either due to how wildcards are expanded. And it gets worse. DoubleMetaphone tries to reduce what it analyzes, well, phonetically with "close" letters (or multiple choices). Some phonetic filte

Re: Wildcards and fuzzy/phonetic query

; a multiterm section in your fieldType, whatever you put in that section >> gets applied whether the underlying class is MultiTermAware or not. >> Which means you can shoot yourself in the foot really bad ... >> >> (…) >> >> Fuzzy searches + wildcards. I don't think you can do that reasonably, but >> I'm not entirely sure. >> >> Best >> Erick >

Re: Wildcards and fuzzy/phonetic query

son: > To answer your first question, yes, you've got it right. If you define > a multiterm section in your fieldType, whatever you put in that section > gets applied whether the underlying class is MultiTermAware or not. > Which means you can shoot yourself in the foot really bad

Re: Wildcards and fuzzy/phonetic query

an really say is give it a try and see how well it works since "good" search results are so domain dependent Fuzzy searches + wildcards. I don't think you can do that reasonably, but I'm not entirely sure. Best Erick On Mon, Oct 8, 2012 at 2:28 PM, Hågen Pihlstrøm Hasle

Re: Wildcards and fuzzy/phonetic query

names from the middle east, Pakistan or India? Is DoubleMetaphone a good match also for names from these countries? Are there any better algorithms? How about fuzzy-searches and wildcards, are they impossible to combine? We actually do three queries for every search, one fuzzy, one phonetic an

Re: Wildcards and fuzzy/phonetic query

cted result, and I'm hoping you guys can >> help me out. >> >> We've indexed a lot of names, and would like to search for a person in our >> system using these names. We previously used Oracle Text for this, and we >> experience that Solr is much faster. S

Re: Wildcards and fuzzy/phonetic query

We previously used Oracle Text for this, and we > experience that Solr is much faster. So far so good! :) But when we try > to use wildcards things start to to wrong. > > We're using Solr 3.4, and I see that some of our problems are solved in > 3.6. Ref SOLR-2438: > h

Re: Wildcards and fuzzy/phonetic query

t;Expert Level Schema Possibilities" at: http://searchhub.org/dev/2011/11/29/whats-with-lowercasing-wildcard-multiterm-queries-in-solr/ You can define your own analysis chain for wildcards as part of your definition and include whatever you want, whether or not it's MultiTermAware and it

Re: Wildcards and fuzzy/phonetic query

slower than desirable. -- Jack Krupansky -Original Message- From: Hågen Pihlstrøm Hasle Sent: Monday, October 08, 2012 11:21 AM To: solr-user@lucene.apache.org Subject: Wildcards and fuzzy/phonetic query Hi! I'm quite new to Solr, I was recently asked to help out on a project where

Wildcards and fuzzy/phonetic query

d a lot of names, and would like to search for a person in our system using these names. We previously used Oracle Text for this, and we experience that Solr is much faster. So far so good! :) But when we try to use wildcards things start to to wrong. We're using Solr 3.4, and I see tha

Re: highlighting and wildcards

Looks like this issue has already been fixed, sorry for the static. I will update and try again. On Thu, Jul 5, 2012 at 5:52 PM, Jamie Johnson wrote: > I am executing a query on a multivalued text field that has the value > of "ZtestForJamie". When I execute this query > > http://localhost:8501

Re: fl Parameter and Wildcards for Dynamic Fields

This appears to be the case. "*" is the only wildcard supported by "fl" before 4.0. -- Jack Krupansky -Original Message- From: Josh Harness Sent: Wednesday, July 04, 2012 9:08 AM To: solr-user@lucene.apache.org Subject: fl Parameter and Wildcards for Dynamic Fi

fl Parameter and Wildcards for Dynamic Fields

I'm using SOLR 3.3 and would like to know how to return a list of dynamic fields in my search results using a wildcard with the fl parameter. I found SOLR-2444 but this appears to be for SOLR 4.0. Am I correct in assuming this isn't doable yet? Plea

Re: whats the equivalent for uint32 FAST unsigned data type in SOLR and how we use wildcards ??

If your uint32 values are less than 2^31, you can use the "int" field type. Otherwise you have to use the "long" field type. Lucene/Solr supports "*" and "?" for wildcards with the usual Unix interpretation. But, some query parsers do not permit leading

Re: whats the equivalent for uint32 FAST unsigned data type in SOLR and how we use wildcards ??

whats the equivalence > for unit32 and alos on using wildcard. > > Regards > Rohit > mailrohi...@gmail.com > > -- > View this message in context: > http://lucene.472066.n3.nabble.com/whats-the-equivalent-for-uint32-FAST-unsigned-data-type-in-SOLR-and-how-we-use-wil

whats the equivalent for uint32 FAST unsigned data type in SOLR and how we use wildcards ??

-FAST-unsigned-data-type-in-SOLR-and-how-we-use-wildcards-tp3991191.html Sent from the Solr - User mailing list archive at Nabble.com.

Re: Question about wildcards

Thanks all for the explanations. Anderson 2012/5/21 Jack Krupansky > And, generally when I see a field that has values like ".2231-7", it > should be a "string" field rather than tokenized text. As a string, you can > then do straight wildcards without surpr

Re: Question about wildcards

And, generally when I see a field that has values like ".2231-7", it should be a "string" field rather than tokenized text. As a string, you can then do straight wildcards without surprises. -- Jack Krupansky -Original Message- From: Jack Krupansky Sent: Mon

Re: Question about wildcards

I change the fieldtype of field to the follow: As you see, i just keep the WhitespaceTokenizerFactory. That's works. Now i could find using "*2231?7", "*2231*7", "*2231-7", "*2231*",".2231-7". How i can see, with this tokenizer the text was not spplitted. Is that

Re: Question about wildcards

1:03 AM To: solr-user@lucene.apache.org Subject: Re: Question about wildcards Hi. In debug mode, the generated query was: field:*2231-7 field:*2231-7 field:*2231-7 field:*2231-7 The analisys of indexing the text .2231-7 produces this result: Index Analyzer .22317

Re: Question about wildcards

Hi. In debug mode, the generated query was: field:*2231-7 field:*2231-7 field:*2231-7 field:*2231-7 The analisys of indexing the text .2231-7 produces this result: Index Analyzer .22317 .22317 .22317 .22317 #1;1322. #1;7 .22317 And for search fo

Re: Question about wildcards

> I have a field that was indexed with the string > ".2231-7". When i > search using '*' or '?' like this "*2231-7" the query > don't returns > results. When i remove "-7" substring and search agin using > "*2231" the > query returns. Finally when i search using  > ".2231-7" the q

edismax, mixing wildcards with specific terms

Hello all Will the edismax QueryParser allow you to mix search terms with wildcards and search terms with specific values in the same query? Or is it better to switch between Query Parsers at run time after analyzing the query? IOW if it contains wildcards, use edismax, otherwise use the

Edismax and leading wildcards

My schema.xml currently has a content field and a content_rev field which is the field run through the reversed wild card filter, my question is does Edismax support using this field? Reading through this jira(https://issues.apache.org/jira/browse/SOLR-1321) it seems to indicate that SolrQueryPars

Re: wildcards and German umlauts

through the > analyzer/filter-chain? > > Greetz, > > Sebastian > > -- > View this message in context: > http://lucene.472066.n3.nabble.com/wildcards-and-German-umlauts-tp499972p2999237.html > Sent from the Solr - User mailing list archive at Nabble.com.

Re: wildcards and German umlauts

gh the analyzer/filter-chain? Greetz, Sebastian -- View this message in context: http://lucene.472066.n3.nabble.com/wildcards-and-German-umlauts-tp499972p2999237.html Sent from the Solr - User mailing list archive at Nabble.com.

  1   2   3   >