[ https://issues.apache.org/jira/browse/SOLR-8113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14951357#comment-14951357 ]
Hoss Man commented on SOLR-8113: -------------------------------- Gus, just read through your patch. My chief concerns are: # you've redefined the semantics of how the {{dest}} string is interpreted when a {{fieldRegex}} is used to identify the source (so there's a back compat break there depending on the value of {{dest}}) # You've designed the "config syntax" for this new feature around the requirement that it can _only_ be used if at least one {{fieldRegex}} is used to identify the source fields ... The original purpose of the {{FieldSelector}} API was to provide more general appoaches for configuring which fields and {{UpdateProcessor}} should care about beyond simple string field name glob/pattern matching. I think that pattern replacements for _destination_ field naming should (in general) be independent of the original selection criteria, so that a user could say something like... bq. I want to make a copy of _any_ {{StrField}} in my documents such that the copy has the same name as the original but with {{_t}} appended. ...and that shold be possible with this feature, regardless of wether the user is using an specific naming convention (ie "*_s") for all StrFields in their index, using some syntax that might look like this... {code} <processor class="solr.CloneFieldUpdateProcessorFactory"> <!-- existing source selector syntax --> <lst name="source"> <str name="typeClass">solr.StrField</str> </lst> <!-- hypothetical new destination pattern syntax --> <lst name="dest"> <str name="pattern">.*</str> <str name="replacement">$0_t</str> </lst> </processor> {code} ...while prefix\->prefix and suffix\->suffix style of cloning similar to what {{copyField}} supports could also be specified. Example: a {{<copyField src="\*_s" dest="\*_t" />}} equivilent would be... {code} <processor class="solr.CloneFieldUpdateProcessorFactory"> <!-- existing source selector syntax --> <lst name="source"> <str name="fieldRegex">^(.*)_s$</str> </lst> <!-- hypothetical new destination pattern syntax --> <lst name="dest"> <str name="pattern">^(.*)_s$</str> <str name="replacement">$1_t</str> </lst> </processor> {code} That's fairly verbose, but if we get the nuts & blots of the general case implemented, then it should be trivial to add syntactic sugar to simplify the configuration... {code} <processor class="solr.CloneFieldUpdateProcessorFactory"> <!-- hypothetical syntactic sugar equivilent to the above example --> <!-- since no other source selector args are specified, assume pattern based cloning --> <str name="pattern">^(.*)_s$</str> <str name="replacement">$1_t</str> </processor> {code} What do you think? > 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 > Attachments: 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org