Re: A defect in Schema API with Add a New Copy Field Rule?
On May 6, 2015, at 8:25 PM, Yonik Seeley ysee...@gmail.com wrote: On Wed, May 6, 2015 at 8:10 PM, Steve Rowe sar...@gmail.com wrote: 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. Yep, used to be relatively common. Perhaps the API could be cleaner though if we supported that by passing an optional numTimes or numCopies? Seems like a sane delete / overwrite options would thus be easier? +1
Re: A defect in Schema API with Add a New Copy Field Rule?
Thanks Steve and Yonik. This now makes sense. Updating the doc will be of a big help. With regards to deleting a copy-field, what I found is that if I have N instances of the same copy-field, I have to issue N deletes to remove them all. This behavior matches with the add and need to be kept. Steve On Wed, May 6, 2015 at 8:10 PM, Steve Rowe sar...@gmail.com wrote: 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
A defect in Schema API with Add a New Copy Field Rule?
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
Re: A defect in Schema API with Add a New Copy Field Rule?
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
Re: A defect in Schema API with Add a New Copy Field Rule?
On Wed, May 6, 2015 at 8:10 PM, Steve Rowe sar...@gmail.com wrote: 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. Yep, used to be relatively common. Perhaps the API could be cleaner though if we supported that by passing an optional numTimes or numCopies? Seems like a sane delete / overwrite options would thus be easier? -Yonik
