[
https://issues.apache.org/jira/browse/SOLR-6003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13980506#comment-13980506
]
Erick Erickson commented on SOLR-6003:
--------------------------------------
Kingston:
Yeah, there's an awful lot of "tribal knowledge" in Solr/Lucene. Partly that's
a result of the speed that some of the mad people code at (yes, I'm a bit
jealous)...
I'm sympathetic to the idea, I just don't see a good way to make it work given
that atomic updates are entirely a request-time construct. We don't require one
to declare "I intend to use atomic updates". And unless we _do_ require such a
thing, I don't see any way to enforce letting the user know that not enough
fields are stored to work as expected. I suppose a flag in the schema like
<safeAtomicUpdate>true|false</safeAtomicUpdate> could trigger such effort but
it'd have to default to "false" in order to not break existing applications.
And again, for a user to know that they needed to set it to "true" implies
they're aware of this limitation so having such a flag may well _not_ have
saved you since you would have to turn it on....
FWIW
> 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]
