On 9/19/2013 6:47 AM, Tanguy Moal wrote: > Quoting http://wiki.apache.org/solr/Atomic_Updates#Caveats_and_Limitations : >> all fields in your SchemaXml must be configured as stored="true" except for >> fields which are <copyField/> destinations -- which must be configured as >> stored="false"
For fields created by copyField, the source field(s) should have stored=true. The destination field should have stored=false. Forgetting about atomic updates for a minute, the reason is pretty simple, especially if you have multiple source fields being dropped in one destination fields: Storing both of them makes your index bigger and makes it take longer to retrieve search results, particularly with version numbers 4.1 or later, because stored values are compressed. I think you've hit on the exact reason why the caveat exists for copyFields and atomic updates -- if the source field isn't stored, then the actual indexed document won't have the source field, which means that the "doesn't exist" value will be copied over to the destination, overwriting any actual value that might exist for that field. It's arguable that it's working as designed, and also working as documented, both in the wiki and the reference guide, which both say that all source fields must be stored. https://cwiki.apache.org/confluence/display/solr/Updating+Parts+of+Documents http://wiki.apache.org/solr/Atomic_Updates You could still file a bug (jira issue) if you like, but given that the documentation is pretty clear, it might not get fixed. Thanks, Shawn
