[
https://issues.apache.org/jira/browse/SOLR-6003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13980465#comment-13980465
]
Erick Erickson commented on SOLR-6003:
--------------------------------------
Hmmm, why not just an additional flag on the field you're declaring? Bad name,
but "requiredToBeStored". Which I'm suggesting entirely facetiously because we
already have 'stored="true" '.
The problem with anything along these lines IMO is that requiring the user to
somehow mark the list of fields required for atomic updates in the schema or
"specially tagging" the field _require_ the user to already understand how
atomic updates work. The original problem statement, as I read it, was to be
able to have this happen automagically. It all seems like it would require
maintenance in addition to the initial effort to no good purpose.
> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
