That is something I didin' t know, but I thought it was mandatory. I' ll try to explain step by step my (I think) logical way to understand it:
- If a field is indexed, you can search by it. - When faceting, you have to index the field (because it can be tokenized and then you would like to facet by their terms). Then, you need to mark as indexed those fields you want to facet by. - If you mark as stored a field, you can return its value with the 'original value' it was stored. - If you facet, you are searching, counting terms and returning values and their counters. Thus, that "returning their values" step is what I thought where 'stored=true' was necessary. If you don' t mark as stored a field indexed and 'facetable', I was expecting to not be able to return their values, so faceting has no sense. Thats what I thought, of course. If it is not necessary, thats perfect: the lighter the data, the better, and one more thing I' ve learned, :-) Anyway, I think that the question is still open: both are dynamic fields, stored (it is not necessary, OK) and indexed. When applying real time requestHandler, i18n* dynamic fields are returned but those *_facet are not. However, when applying the default /select requestHandler and finding by the document id, both i18n* and *_facet fields are returned. You can try it with Solr 5.1, the version I' m currently using. The only differences between them are: - Regular expression: i18n* VS *_facet - Multivalued: *_facet are multivalued. Regards, - Luis Cappa 2015-05-14 18:32 GMT+02:00 Yonik Seeley <ysee...@gmail.com>: > On Thu, May 14, 2015 at 10:47 AM, Luis Cappa Banda <luisca...@gmail.com> > wrote: > > Hi Yonik, > > > > Yes, they are the target from copyFields in the schema.xml. This *_target > > fields are suposed to be used in some specific searchable (thus, > tokenized) > > fields that in the future are candidates to be faceted to return some > > stats. For example, imagine that you have a field storing a directory > path > > and you want to search by. Also, you may want to facet by the whole > > directory path value (not just their terms). Thats why I' m storing both > > field values: searchable and tokenized one, string and 'facet candidate' > > one. > > OK, but you don't need to *store* the values in _facet, right? > -Yonik > -- - Luis Cappa
