[jira] [Commented] (SOLR-15150) add request level option to fail an atomic update if it can't be done 'in-place'
[ 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: [email protected] For additional commands, e-mail: [email protected]
[jira] [Commented] (SOLR-15150) add request level option to fail an atomic update if it can't be done 'in-place'
[ https://issues.apache.org/jira/browse/SOLR-15150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17285523#comment-17285523 ] ASF subversion and git services commented on SOLR-15150: Commit 1c7dac83075a9e214311a85c0f85dd72fe6f444a in lucene-solr's branch refs/heads/master from Chris M. Hostetter [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=1c7dac8 ] SOLR-15150: New update.partial.requireInPlace=true option to prevent any partial document updates that can't be done In-Place > 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: [email protected] For additional commands, e-mail: [email protected]
[jira] [Commented] (SOLR-15150) add request level option to fail an atomic update if it can't be done 'in-place'
[
https://issues.apache.org/jira/browse/SOLR-15150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17283283#comment-17283283
]
Chris M. Hostetter commented on SOLR-15150:
---
David: yeah, we probably intermix "atomic" and "partial" too much, and conflate
the atomic nature of the partial updates with the atomic nature of optimistic
concurrency updates – even when the users aren't doing that.
So agreed: better to use "partial" here to clarify what aspect we're dealing
with.
Ishan: I had originally considering the verb "force" (and i realize now it stil
lingers in a test variable) but it felt really missleading and I'd prefer we
avoid it...
Through the lens of a novice user "forceX" makes me think I'm telling solr "Hey
solr do X even if you wouldn't by default and even if it might break something"
... similar to {{"rm -f"}} or {{"git push --force"}} ... but what we want to
convey is *NOT* that this is a way to _force_ the update to be done in-place
(because we can't actually promise that) .. what we want to convey is that this
is way for the user to say "When i do a partial update, I expect that _either_
the update be done in place, or it must fail"
"Require" felt a little better, because it seemed more like a _request_ if that
makes sense? ... "I require that Solr do X" felt like a good english language
equivalent, to the sentiment I was going for, because Solr can either satisfy
the request, or so "I'm not capable of doing that" (ie:fail)
(I had briefly considered using the verb "assert" as in
{{"assert.inplace.atomic.update"}} or {{"update.partial.assertInPlace"}} but
that felt too Java/C-ish for general solr users)
Omitting any "verb" (either "force" or "require") and just go with something
like {{"update.partial.inplace"}} is an interesting idea, but i feel like it's
too ... "weak" is the closest word i can think of i guess? ... compared to how
this would behave: {{update.partial.inplace=true}} it feels more like a way to
override a default, (that might otherwise be hueristicly determined) and makes
me think that {{update.partial.inplace=false}} would be a way to indicate that
solr should _never_ do my update inplace, which isn't want we want the
(default) {{"false"}} value to mean.
So I think on balance at this point I like David's suggestion of
{{"update.partial.requireInPlace"}} the best so far?
> 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: [email protected]
For additional commands, e-mail: [email protected]
[jira] [Commented] (SOLR-15150) add request level option to fail an atomic update if it can't be done 'in-place'
[ https://issues.apache.org/jira/browse/SOLR-15150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17283179#comment-17283179 ] Ishan Chattopadhyaya commented on SOLR-15150: - +1 Hoss, this issue is very useful. How about "forceInPlaceUpdate" or "forceInPlace"? Or maybe just "inplace"? > 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: [email protected] For additional commands, e-mail: [email protected]
[jira] [Commented] (SOLR-15150) add request level option to fail an atomic update if it can't be done 'in-place'
[ 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: [email protected] For additional commands, e-mail: [email protected]
