[ 
https://issues.apache.org/jira/browse/SOLR-15150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17285545#comment-17285545
 ] 

ASF subversion and git services commented on SOLR-15150:
--------------------------------------------------------

Commit 484a336c4fe344f96fd7370f26d56a02256c1dc2 in lucene-solr's branch 
refs/heads/branch_8x from Chris M. Hostetter
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=484a336 ]

SOLR-15150: New update.partial.requireInPlace=true option to prevent any 
partial document updates that can't be done In-Place

(cherry picked from commit 1c7dac83075a9e214311a85c0f85dd72fe6f444a)


> 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
>         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

Reply via email to