On Sun, Dec 16, 2018 at 05:44:30PM -0800, Erick Erickson wrote: > No, the idea is that you have N single valued fields, one for each of > the MV entries you have. The copyField dest would be MV, and only used > in those cases you wanted to match across values. Not saying that's a > great solution, or if it would even necessarily work but thought it > worth mentioning.
Ok, then my initial document with MV fields: > "content_txt":["001 first","002 second"] would become: > "content1_t":"001 first" > "content2_t":"002 second" > "_copiedfield_":["001 first","002 second"] And then the initial user query: > content_txt:(first AND second) would become: > content1_t:(first AND second) OR content2_t:(first AND second) Depending on the length of the initial array, each document will have a different number of contentx_t. This means some management like a layer between the user and the parser, to extend the query with the maximum possible contentx_t fields in the collection. (with max=100 for performance reason?) QUESTION: -------- is the MV limitation a *solr parser* limitation, or a *lucene* limitation. If it is the latter, writing my own parser would be an option isn't ? -- nicolas
