[
https://issues.apache.org/jira/browse/SOLR-15150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris M. Hostetter resolved SOLR-15150.
---------------------------------------
Fix Version/s: 8.9
master (9.0)
Resolution: Fixed
> 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
> Reporter: Chris M. Hostetter
> Assignee: Chris M. Hostetter
> Priority: Major
> Fix For: master (9.0), 8.9
>
> Attachments: SOLR-15150.patch, SOLR-15150.patch
>
>
> 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
