Hi Victor,
your wages are hopefully more than what costs disk space, nowadays?
I don't want to spoil the fun in thinking of new challenges when it
comes to SOLR, but from a project management point of view I would buy
some more storage and get it done with copyfield and two requesthandlers
that choose the stemmed versus the non-stemmed fields to search on.
(Given that an index is a temporary storage and does not require highest
quality disk RAID systems.)
Well, I'm probably being naive...
To add something valuable to this post:
Maybe you could create two cores that point to the same index. This
might be possible if you use the same index path in both solrconfig.xml?
(I haven't tried it.) Use the exact same schema but with different
synonym files. If one synonym file is empty, and the other contains your
stemming stuff, then querying one core versus querying the other should
have the effect you expect?
No offense,
Chantal
On Fri, 2011-10-14 at 14:36 +0200, Victor wrote:
> Hi Erick,
>
> First of all, thanks for your posts, I really appreciate this!
>
> 1) Yes, we have tested alternative stemmers, but I admit that a definite
> decission has not been made yet. Anyway, we definately do not want to create
> a stemmed index because of storage issues and we definately want to be able
> to allow the end-user to turn it on and off. So choosing a different stemmer
> does not solve my problem of wanting to switch between stemming/non-stemming
> without additional indexes.
>
> 2) Rant granted :) And I definately agree with you. It is always a challenge
> to find a balance between what a customer wants and how far you really want
> to go to in achieving a solution (that does not conflict too much with the
> maintainability of the system).
>
> But, I do think that the requirements are not that outragious. It seems to
> me reasonable that once you have created an index it would be nice to be
> able to use that index in different ways. After all, the only thing I want
> is apply different query analyzers (mind you, I am not formatting the
> tokens, what could possibly result in index/query token conflicts, I am
> merely expanding query possibilities here by adding synonyms, the rest stays
> the same).
>
> Another good example could be that you want to index a field that contains
> text in different languages. Would it not be nice then to be able to define
> optimized query analyzers on that field, one for each language? You could
> then access them using the q parameter: q=<field>:<language>:<search term>,
> where <language> is the name of the query analyzer to use. It seems to me to
> be a nice feature. Could be a big change though, because I assume that at
> the moment the analyzers have hard-coded names ("index" and "query").
>
> 3) Yep, I was also looking into this (because other options seemed to be
> vaporizing). Don't know if I'm going to use suffixes or maybe add a trigger
> word like @stem@. Depends on what the scope of the called method is. I
> prefer the trigger word @stem@ variant because I can then just insert that
> without needing to parse the query string to find out what the actual seach
> words are that I need to suffix.
>
> Cheers and again, thanks for helping me on this,
> Victor
>
>
> --
> View this message in context:
> http://lucene.472066.n3.nabble.com/Multiple-search-analyzers-on-the-same-field-type-possible-tp3417898p3421522.html
> Sent from the Solr - User mailing list archive at Nabble.com.
