Chris M. Hostetter created SOLR-15150:
-----------------------------------------
Summary: add request level option to fail an atomic update if it
can't be done 'in-place'
Key: SOLR-15150
URL: https://issues.apache.org/jira/browse/SOLR-15150
Project: Solr
Issue Type: New Feature
Security Level: Public (Default Security Level. Issues are Public)
Reporter: Chris M. Hostetter
Assignee: Chris M. Hostetter
When "In-Place" DocValue updates were added to Solr, the choice was made to
re-use the existing "Atomic Update" syntax, and use the DocValue updating code
if possible based on the index & schema, otherwise fall back to the existing
Atomic Update logic (to re-index the entire document). In essence, "In-Place
Atomic Updates" are treated as a (possible) optimization to "regular" Atomic
Updates
This works fine, but it leaves open the possibility of a "gotcha" situation
where users may (reasonably) assume that an update can be done "In-Place" but
some aspect of the schema prevents it, and the performance of the updates
doesn't meet expectations (notably in the case of things like deeply nested
documents, where the re-indexing cost is multiplicative based on the total size
of the document tree)
I think it would be a good idea to support an optional request param users can
specify with the semantics that say "If this update is an Atomic Update, fail
to execute it unless it can be done In-Place"
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
