[jira] [Commented] (SOLR-15150) add request level option to fail an atomic update if it can't be done 'in-place'

["David Smiley (Jira)" <ji...@apache.org>]

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

David Smiley commented on SOLR-15150:
-------------------------------------

+1 LGTM and great testing as usual

RE "require.inplace.atomic.updates". honestly I cringe seeing flags named like an English sentence.  I prefer the dots scope the module and then use camelCase for the option, e.g. "update.partial.requireInPlace".  I'm not a fan of Solr's overuse of this word "atomic" when really it's the "partial"-ness that is more perceivable by the user as what's happening.  I view the "atomic"-ness as an implementation detail to the "partial" aspect.  It could be argued the "atomic" aspect is more visible when users choose to specify a version constraint... but few users even do that, and even then I'd rather say something like "conditional update".

> 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
>            Priority: Major
>         Attachments: 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org