David Smiley commented on SOLR-11336:

You forgot:

bq. The docs for isVersionNewEnough was modified to say it returns "the solr 
version" instead of "true". But no, it's true/false. Perhaps you were toying 
with some refactoring to this method and backed out.

I kinda wonder if {{versionFields}} is warranted versus simply splitting 
{{versionField}}, particularly given I suspect it'd be rare to want to use 
multiple fields.  But whatever.

> 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

To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to