Chris Hostetter wrote:
: Syntax aside, the major implication is that DynamicCopy would need a
: virtual function:
:   SchemaField getTargetField()

I don't think i've ever looked at DynamicField before today ... but i see
what you're talking about, you mean that "final SchemaField targetField"
would need to be replaced with "SchemaField getTargetField(String
sourceField)" right?


exactly.


yeah that seems simple enough, i'm not sure what Yonik ment by this
comment...

  // Instead of storing a type, this could be implemented as a hierarchy
  // with a virtual matches().
  // Given how often a search will be done, however, speed is the overriding
  // concern and I'm not sure which is faster.

... i don't see how this ever comes into play with search.


I don't either... I think it only happens at indexing. ResponseWriters do not know (or care) if a field is from a copy field or not.


on the issue of syntax and regex vs glob, i would leave it as a glob for
now since that's already supported by the syntax and the impl ...

agreed.


if we want to support regexes that should be done seperately in
DynamicReplacement where it can be leveraged by both <copyField> and
<dynamicField>


glob is fine for what i need.


Thanks for the feedback, i'll post something on JIRA soon.

ryan

Reply via email to