[
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-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
