It is not that I want it. I just can't reproduce it even though I read it as an expected behaviour.
So I wondered if something has been changed since the warning was written, or if I had misunderstood something. ons. d. 14. nov. 2018 17.09 skrev Erick Erickson <erickerick...@gmail.com>: > I'm a little confused on what you're trying. Say your source field is > Y and your destination field X. Are you saying that you want your > destination field X to contain both the old value of field Y and the > new value of field Y when you atomically update that field Y? > > Hmmmm, I'm actually not sure what happens in that case. The original > admonition was specifically because the above is usually undesirable > behavior. Imagine you have a source field name and destination field > name_d. The first time you add the doc it will have "erick" in both. > Now I atomically update field "something_else". Your doc will still > have "erick" in name, but (probably) "erick", "erick" in name_d. > > What I'd probably do to deal with selectively preserving some > destinations of copyFields is use an updateprocessor, perhaps > ScriptUpdateProcessor to do the right thing an a per-field basis. > > Best, > Erick > On Wed, Nov 14, 2018 at 7:56 AM Jon Kjær Amundsen <j...@udbudsvagten.dk> > wrote: > > > > Reading up on atomic updates, the Solr reference guide states the > following: > > > > The core functionality of atomically updating a document requires that > all > > fields in your schema must be configured as stored (stored="true") or > > docValues (docValues="true") except for fields which are <copyField/> > > destinations, which must be configured as stored="false" > > > > Reading the next section it seems the reasons for this is that any > > destination fields will be indexed with both the old and the new value. > > > > However, i've tried the atomic update functionality updating both fields > > unrelated to the destination fields and fields copying to the fields and > I > > can't see any problems in the stored content of the destination field, > and > > I can't query a document based on old content in a destination field if > it > > has been overwritten. > > > > My question is: How should I understand the warning, and can it be save > to > > use atomic updates even though you have stored destination fields? > > > > I am on Solr 7.1 > > > > Venlig hilsen/Best regards > > > > *Jon Kjær Amundsen* > > Information Architect & Product Owner > > *UdbudsVagten A/S* >
