: If neither of these is the case, then we still might copy the value to one : or more other fields due to a wildcard match in a copyField.
Darren, glancing at your patch, I see you added a simple test for copying from *_t to text -- but *_t is an existing dynamicField .. could you perhaps add some more test cases covering these new situations you've added support... <copyField source="*_notADeclaredDynamicField" dest="text"/> <copyField source="notADeclaredField" dest="text"/> Also; the paranoid part of my brain wonders if the <copyField> directive should be left as it is, and a new <dynamicCopyField> directive should be added to support wildcards in the source ... i worry that some weird sick individual out there might acctually want a field name that contains a "*" in it, and we've not eliminated the ability for them to use that field with a copyField (this was the same motivation for the <field> <dynamicField> distinction) : The syntax you described below, where the destination contains a wildcard, : is not supported by this implementation. The destination must be a an : explicit field, meeting the conditions above. : If I have a <copyField source="*_a" dest="*_b"/> I'm acctually in favor of this approach .. Yonik's idea once upon a time of supporting <copyField source="*_a" dest="*_b"/> allways scared me, not only does it raise hte question: is that legal as schema creation even if i don't have a <dynamicField name="*_b" ... /> but i do have a lot of filds whose names end with _b? but it opens the door for <copyField source="*_a" dest="b_*"/> ... how should that be treated if in addition to a dynamicField with the prefix b_* i also have an explicitly field named "b_foo" .. normal matching rules say that if i add a doc with a field named "b_foo" it's subject to the FieldType of the explicitly declared field, but is that the "right" thing to do when we're in a copyField relationship where the source was dynamic? ...like i said, i'm paranoid. -Hoss
