Word de-compounding using the terms in the index?

Say for instance at query time, I would like to use the terms within my index to de-compound query Terms. The current solution I'm aiming for is to build a suggester like component into the query pipeline using TSTLookups. Since all Lookups require to be SolrCoreAware, that is; rebuilt when

FunctionQueryNode pipeline?

I'm wondering if anyone has attempted this. The general idea is to have a FunctionQueryNode, Builder and Pipeline, where functions appear as foo(param) within the query string. Further down the pipeline, Solr has provided functionality for handling ValueSources. The only issue I have

Re: AndQueryNode to NearSpanQuery

That is a really good idea. I'll have to try that. -- View this message in context: http://lucene.472066.n3.nabble.com/AndQueryNode-to-NearSpanQuery-tp3061286p3063668.html Sent from the Solr - User mailing list archive at Nabble.com.

Re: AndQueryNode to NearSpanQuery

Thanks for the correction! I thought I had read that phrases were assumed to be in order and the slop was the distance between them. I'll look into this also. -- View this message in context: http://lucene.472066.n3.nabble.com/AndQueryNode-to-NearSpanQuery-tp3061286p3063673.html Sent from the

Re: AndQueryNode to NearSpanQuery

Thanks for your help, great solution! Turned out perfectly. Too bad they don't actually add this to the sdk. -- View this message in context: http://lucene.472066.n3.nabble.com/AndQueryNode-to-NearSpanQuery-tp3061286p3066035.html Sent from the Solr - User mailing list archive at Nabble.com.

AndQueryNode to NearSpanQuery

I'm having an issue with how I can go about achieving this and I was wondering if someone had any pointers... My goal: To produce searches where AndQueries are ORed with a SpanNearQuery, therefore boosting the results higher because they appeared closer. The only use case I'm concerned with is

Re: AndQueryNode to NearSpanQuery

Hey Erick, Thanks for the feedback, but I it doesn't particularly solve my problem. The issue with doing a boosted phrase clause is that the terms have to be in order to be considered a hit. I'm seeking a solution where the terms can be near another term in any direction. If I were to use a

[Contribution] Multiword Inline-Prefix Autocomplete Idea

At my company. I've been spending some time figuring out the best approach for inline prefix Auto completion. Most of the support for auto completion is based solely on prefix matching, as it can jump to a certain term within a field quickly and break the enumeration loop when the prefix no

Re: [Contribution] Multiword Inline-Prefix Autocomplete Idea

Ahh yes, thanks for the suggestions! I've implemented them. I thought about you're second point previously and had encountered that issue. Once it's tokenized, I don't believe there is a way to get the full string back from the token stream. -- View this message in context:

RE: Synonym Filter disable at query time

Just a heads up on a solution. copyField wasn't need, but a new fieldType and a non-indexed, non-stored field was added. Within a new Synonym processor that executes right before the AnalyzerQueryNodeProcessor, I was able to modify the field name for each node to point at the new field.

Synonym Filter disable at query time

I would like to be able to disable the synonym filter during runtime based on a query parameter, say 'synoynms=true' or 'synonyms=false'. Is there a way within the AnaylzerQueryNodeProcessor or QParser that I can remove the SynonymFilter from the AnalyzerAttributes? It seems that the Analyzer

RE: Synonym Filter disable at query time

Awesome thanks! Also, you wouldn't happen to have any insight on boosting synonyms lower than the original query after they were stemmed, would you? Say if I had synonyms turned on: The TokenStream is setup to do Synonyms - StopFilter - LowerCaseFilter - SnowballPorter. Say I search for

RE: Synonym Filter disable at query time

Actually now that I think about it, with copy fields I can just single out the Synonym reader and boost from an earlier processor. Thanks again though, that solved a lot of headache! -- View this message in context: