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

Michael Braun commented on SOLR-11336:
--------------------------------------

Whoops thanks [~dsmiley], will have that fixed on the next version of the patch.

Regarding versionFields vs splitting versionField, what do you mean? The case 
we have is a document has multiple version fields - it wouldn't simply be 
enough to have n DocBasedVersionConstraintsProcessors, where n is the number of 
versions, 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, which was only greater than. What do you think? Would that be a cleaner 
solution?

> 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

Reply via email to