[ 
https://issues.apache.org/jira/browse/SOLR-6003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13976824#comment-13976824
 ] 

Shawn Heisey commented on SOLR-6003:
------------------------------------

bq. How would you distinguish a situation where atomic updates were not being 
used from one that did?

If we were to scan the schema for atomic update suitability when the schema 
object is created or updated, we could set a flag in the schema object.

Then we could log a warning message each time an atomic update is done against 
a schema that doesn't meet the criteria.  Someone might have a situation where 
the unstored fields are included with every update.  If it is too expensive to 
detect that situation, we can provide a config option to turn off the warning.


> 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]

Reply via email to