Re: Atomic updates and stored CopyTo destination fields
On 11/14/2018 10:35 AM, Jon Kjær Amundsen wrote: 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. To my knowledge, nothing has changed in this area. If a copyField destination is stored, then I think most people would be unhappy with the results of running an atomic update, especially if fields related to that copyField are changed with the update. Thanks, Shawn
Re: Atomic updates and stored CopyTo destination fields
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 : > 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? > > H, 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 > 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 > > 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* >
Re: Atomic updates and stored CopyTo destination fields
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? H, 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 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 > 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*
Atomic updates and stored CopyTo destination fields
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 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*
