All fields are being explicitly populated on the initial document load
without copyFields, and the atomic updates come after.
This situation actually came up while we were planning removing copyField
properties from one of the fields in a schema for a new collection.
On Tue, Apr 25, 2017 at 3:54 PM Erick Erickson <erickerick...@gmail.com>
wrote:
> How is "otherText" getting values in the first place? If
> it's the destination of a copyField directive, it'll be repopulated
> if the source of the copyField is stored=true.
>
> Best,
> Erick
>
> On Tue, Apr 25, 2017 at 12:40 PM, Chris Ulicny <culicny@iq.media> wrote:
> > Hello all,
> >
> > Suppose I have the following fields in a document and populate all 4
> fields
> > for every document.
> >
> > id: uniqueKey, indexed and stored
> > integer_field: indexed and stored
> > text_field: indexed and stored
> > othertext_field: indexed but not stored
> >
> > No default values, multivalues, docvalues, copyfields, or any other
> > properties set.
> >
> > If I make an atomic update to a document like the following:
> > {"id":"1", "integer_field":{set: "1000"}}
> >
> > what should we expect to happen with the othertext_field?
> >
> > In a few tests, it seemed like the original indexed values of the record
> > were preserved.
> >
> > I know to use atomic updates all fields should be stored since the
> document
> > is read and reindexed internally, but was curious if there was any
> > consistency or expected results for the state of othertext_field after an
> > atomic update.
> >
> > Thanks,
> > Chris
>
