Hi Steve, It’s by design that you can copyField the same source/dest multiple times - according to Yonik (not sure where this was discussed), this capability has been used in the past to effectively boost terms in the source field.
The API isn’t symmetric here though: I’m guessing deleting a mutiply specified copy field rule will delete all of them, but this isn’t tested, so I’m not sure. There is no replace-copy-field command because copy field rules don’t have dependencies (i.e., nothing else in the schema refers to copy field rules), unlike fields, dynamic fields and field types, so delete-copy-field/add-copy-field works as one would expect. For fields, dynamic fields and field types, a delete followed by an add is not the same as a replace, since (dynamic) fields could have dependent copyFields, and field types could have dependent (dynamic) fields. delete-* commands are designed to fail if there are any existing dependencies, while the replace-* commands will maintain the dependencies if they exist. Steve > On May 6, 2015, at 6:44 PM, Steven White <swhite4...@gmail.com> wrote: > > Hi Everyone, > > I am using the Schema API to add a new copy field per: > https://cwiki.apache.org/confluence/display/solr/Schema+API#SchemaAPI-AddaNewCopyFieldRule > > Unlike the other "Add" APIs, this one will not fail if you add an existing > copy field object. In fact, after when I call the API over and over, the > item will appear over and over in schema.xml file like so: > > <copyField source="author" dest="text"/> > <copyField source="author" dest="text"/> > <copyField source="author" dest="text"/> > <copyField source="author" dest="text"/> > > Is this the expected behaviour or a bug? As a side question, is there any > harm in having multiple "copyField" like I ended up with? > > A final question, why there is no Replace a Copy Field? Is this by design > for some limitation or was the API just never implemented? > > Thanks > > Steve
