lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luis Cappa Banda <>
Subject Re: Real-Time get and Dynamic Fields: possible bug.
Date Thu, 14 May 2015 16:49:08 GMT
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.


- Luis Cappa

2015-05-14 18:32 GMT+02:00 Yonik Seeley <>:

> On Thu, May 14, 2015 at 10:47 AM, Luis Cappa Banda <>
> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message