[
https://issues.apache.org/jira/browse/SOLR-6003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13981117#comment-13981117
]
Shawn Heisey commented on SOLR-6003:
------------------------------------
[~kduffie], you are reading it correctly.
When an atomic update request is made, the first thing the code does is use the
uniqueKey value to query the index, then use the stored fields found in the
index to populate the new SolrInputDocument object. At this point, any field
that is not stored will not be present in the new SolrInputDocument. Once the
new document is populated, the atomic update operations are applied.
If you are using "set" as your action, it would not be a problem for that field
to be unstored. I believe a "removeAll" action is planned for a future
release, and that would also not be a problem with an unstored field.
When the action is "add" or "inc", there is an assumption of an existing value
in the field. A new "remove" action is already in the code for Solr 4.9, which
also has an assumption of an existing value.
It would be a *MAJOR* change (probably at both the Solr and the Lucene levels)
to support updating a document containing unstored fields without providing the
values for those fields. It would be even harder (possibly impossible) to
support doing add/inc/remove options on a field that's not stored.
> JSON Update increment field with non-stored fields causes subtle problems
> -------------------------------------------------------------------------
>
> Key: SOLR-6003
> URL: https://issues.apache.org/jira/browse/SOLR-6003
> Project: Solr
> Issue Type: Bug
> Components: update
> Affects Versions: 4.7.1
> Reporter: Kingston Duffie
>
> In our application we have large multi-field documents. We occasionally need
> to increment one of the numeric fields or add a value to a multi-value text
> field. This appears to work correctly using JSON update. But later we
> discovered that documents were disappearing from search results and
> eventually found the documentation that indicates that to use field
> modification you must store all fields of the document.
> Perhaps you will argue that you need to impose this restriction -- which I
> would hope could be overcome because of the cost of us having to store all
> fields. But in any case, it would be better for others if you could return
> an error if someone tries to update a field on documents with non-stored
> fields.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
