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

Erick Erickson commented on SOLR-6003:
--------------------------------------

see: https://issues.apache.org/jira/browse/LUCENE-4258

bq: ..this situation can be checked once at the time when the schema is first 
used to create the collection/core...

It's still a "false error".

How would you distinguish a situation where atomic updates were _not_ being 
used from one that did? There's nothing in the schema itself that says "we're 
going to use atomic updates", it's purely how the index is going to be _used_. 
So there'd be nothing to check. 



> 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