[
https://issues.apache.org/jira/browse/SOLR-11336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16385529#comment-16385529
]
David Smiley commented on SOLR-11336:
-------------------------------------
bq. Regarding versionFields vs splitting versionField, what do you mean?
I only mean it in terms of configuration -- that's all. Split versionField by
comma is the alternative I suggest. It's simpler to implement, simpler to
understand the parameters this URP takes (1 required versus an XOR between 2).
It just takes a white lie that "versionField" is singular when in fact it could
be multiple. I think it's not a big deal considering the need for more than
one is uncommon. That's all... I'm not particularly opinionated about this so
if you'd rather keep how you've already coded it now then fine.
bq. unless there was a version of the processor (which can now be accomplished
by subclassing and overriding versionInUpdateIsAcceptable) that accepted
greater than or equal numbers and passed them along until the last one
I don't have an opinion because I haven't thought through what you say
admittedly; I just want to allow this URP to be more subclass-able to allow
more customization. You've thought through this and I trust your judgement.
> DocBasedVersionConstraintsProcessor should be more extensible and support
> multiple version fields
> -------------------------------------------------------------------------------------------------
>
> Key: SOLR-11336
> URL: https://issues.apache.org/jira/browse/SOLR-11336
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Affects Versions: master (8.0)
> Reporter: Michael Braun
> Priority: Minor
> Attachments: SOLR-11336.patch, SOLR-11336.patch, SOLR-11336.patch
>
>
> DocBasedVersionConstraintsProcessor supports allowing document updates only
> if the new version is greater than the old. However, if any behavior wants to
> be extended / changed in minor ways, the entire class will need to be copied
> and slightly modified rather than extending and changing the method in
> question.
> It would be nice if DocBasedVersionConstraintsProcessor stood on its own as a
> non-private class. In addition, certain methods (such as pieces of
> isVersionNewEnough) should be broken out into separate methods so they can be
> extended such that someone can extend the processor class and override what
> it means for a new version to be accepted (allowing equal versions through?
> What if new is a lower not greater number?).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
