[
https://issues.apache.org/jira/browse/SOLR-6003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13980531#comment-13980531
]
Hoss Man commented on SOLR-6003:
--------------------------------
if i'm correctly following the gist of what you guys are aiming for, the
"warn/fail if it looks like they shouldn't be using atomic updates" type logic
you are imagining doesn't account for dynamicFields, or the use cases i've seen
in the wild where users deliberately have non-stored fields (to save space)
that they *might* replace with new values on atomic update, or they just leave
the field out of the update as a way to remove the value. (a deliberate choice
of one or the other is made by their update client on every update)
I think at the end of the day, nothing we can imagine doing to try and help
people with this type of problem is going to overcome the problem shawn & erick
already alluded to: any sort of configuration/warning/setting to help Solr know
what type of situation is "not ok" is something the user would have to
explicitly set, which would require the user to know about the limitation in
the first place, which would eliminate the need for any special
configuration/warning/setting.
(The one exception to this might be situations where the user *conifiguring*
solr is aware of the situation, but wants to leave some fields non-stored and
needs a way to fail "incomplete" updates that don't specify those fields - that
could be done fairly easily with an UpdateProcessor)
> 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
