hossman wrote:
>
> it ensures the schema creator must clearly thinks through exactly what
> should be copied where -- otherwise you might have an existing mappings
> of x->z and y->z that you don't consider/remember when adding a->x (or
> worse: a->x and a->y)
>
Hmm, I can see your reasoning here.
hossman wrote:
>
> this part of yourquestion doesn't make sense to me ...
>
I'll try to give a more substantial example(which I should properbly have
done in the first plac): We're searching for products and got a (short)
title and (long) description as well as brands, shops etc.
All the small fields are copied into a catch-all field 'text' which involves
verstatile analysis. The description is not copied (to reduce the noise). To
be able to switch at runtime to a field where also the description is
considered, we thought it'd be a good idea to copy the content of 'text'
along with the description into an extended catch-all field.
This would just need a very basic, i.e. WhiteSpace-, tokenizer and no
further filters.
Of course this functionality is not vitally important, but I still wanted to
make sure I'm not missing s.th. obvious here. I guess making the copyFields
recursive does rise quite some questions, and doesn't really justify the
hassle, just for not having to copy the 10 lines ;-)
Thx for your explanation,
Axel
--
View this message in context:
http://www.nabble.com/cahining-copyFields-tp19839265p19846541.html
Sent from the Solr - User mailing list archive at Nabble.com.
