In SOLR why would a field be non-stored and non-indexed?

4
votes

In Solr's documentation around atomic updates, they mention that a field should be non-indexed and non-stored.

https://lucene.apache.org/solr/guide/7_6/updating-parts-of-documents.html#in-place-update-example

An atomic update operation is performed using this approach only when the fields to be updated meet these three conditions:

are non-indexed (indexed="false"), non-stored (stored="false"), single valued (multiValued="false") numeric docValues (docValues="true") fields;

<field name="price" type="float" indexed="false" stored="false" docValues="true"/>

What would be an example use-case of doing this?

Wouldn't that mean that it's not queryable and not returned in responses?

1
solrlucene
Here is a good example on when this is a good approach: stackoverflow.com/questions/22287584/solr-index-vs-stored/… – Hector Correa
@HectorCorrea thanks! – d-_-b
The field can still be used when boosting etc. when you have docValues enabled. – MatsLindh

1 Answers

6
votes

The thing to understand in this context is that setting "docValues=true" is intended as an alternative to "index=true": still making the field "queryable" but in a column oriented (non-inverted) index.

[...] a way of recording field values internally that is more efficient for some purposes, such as sorting and faceting, than traditional indexing.

Actually being able to make atomic updates in a sort/facet-dedicated-field is an example use-case !

Remember that a field with docValues enabled can still be fetched even if set as "stored=false", allowing for example to retrieve values using the fl parameter. That is because docValues are in a way "always" stored, how depends on docValuesFormat that defaults to "Memory" (meaning doc values are stored in heap).

DocValues fields also relies on useDocValuesAsStored that defaults to true, meaning the field behaves as if it were defined as stored="true" even if defined as stored="false".