> For in-place updates, the documentation states that only the fields being > modified are updated, but does that mean that all other fields don't need > to be stored?
Correct, in general there's no need to store the other fields. However, there's a niche case where if a simultaneous DeleteByQuery command and in-place update command get re-ordered on a replica, and it ends up deleting the document that is required to be updated, the replica will fetch the document from leader. At that point, non-stored fields can be lost. So, if you don't use DeleteByQuery commands you can safely stop storing other fields. > we are calculating authority-like and popularity > scores for our documents This is the ideal usecase for in-place updates. On Thu, Mar 30, 2017 at 1:13 AM, Elaine Cario <etca...@gmail.com> wrote: > I need some clarity on atomic vs in-place updates. For atomic I understand > that all fields need to be stored, either explicitly or through docValues, > since the entire document is re-indexed. > > For in-place updates, the documentation states that only the fields being > modified are updated, but does that mean that all other fields don't need > to be stored? > > My real problem is that we are calculating authority-like and popularity > scores for our documents in an external process, and would actually prefer > to use something like ExternalFileField for those values. But EFF is not > really SolrCloud-friendly, and we have a fairly mature indexing process in > place already. It might be more palatable for us to do an in-place update, > rather than deal with the operational issues of dropping files into every > shard of a collection, but only IF we don't need to change our existing > schemas to store everything which might not be stored today. > > Thanks in advance. >
