[
https://issues.apache.org/jira/browse/SOLR-8113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gus Heck updated SOLR-8113:
---------------------------
Attachment: SOLR-8113.patch
All your updates look fine. I notice that most of my tests disappeared, but
probably there was a lot of overlap with your original tests (which also
verified boost maintenance whereas mine did not). I'm trusting that you are
happy with the coverage there.
I also added 2 more validations of config parameters to give nicer messages if
someone uses 3 or 4 of the possible parameters (src/dest/pattern/replacement).
This would have been caught by the "extra params" check at the end but is less
clear. I also moved the extra params check to the main method as a safety net
for all cases.
I had been on the fence WRT replace vs replaceAll, (simplicity vs flexibility)
but in looking around I notice FieldNameMutatingUpdateProcessor uses replace
all. Consistency seems like a good idea.
> Accept replacement strings in CloneFieldUpdateProcessorFactory
> --------------------------------------------------------------
>
> Key: SOLR-8113
> URL: https://issues.apache.org/jira/browse/SOLR-8113
> Project: Solr
> Issue Type: Improvement
> Components: update
> Affects Versions: 5.3
> Reporter: Gus Heck
> Assignee: Hoss Man
> Attachments: SOLR-8113.patch, SOLR-8113.patch, SOLR-8113.patch,
> SOLR-8113.patch
>
>
> Presently CloneFieldUpdateProcessorFactory accepts regular expressions to
> select source fields, which mirrors wildcards in the source for copyField in
> the schema. This patch adds a counterpart to copyField's wildcards in the
> dest attribute by interpreting the dest parameter as a regex replacement
> string.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
