On 7/15/2015 8:55 AM, Martínez López, Alfonso wrote: > in some cases it can be necessary to have the copy field stored. My Solr > instance is used by some legacy applications that need to retrive fields by > some especific field names. That's why i need to mantain 2 copies of the same > field: one with the old name and other for the new name (that is provided by > others applications). > > In my case I could work this out at a higher lever but it would be very > helpful it can be solve in the schema.xml.
This is understandable ... but unless a new feature is created, stored copyField destinations are incompatible with Atomic Updates. If we do build a new feature, we'd need to figure out exactly how Solr should behave by default, and possibly whether there should be a configuration option to choose old or new behavior. It might be a good idea to have DistributedUpdateProcessor (or possibly the AtomicUpdateDocumentMerger that it uses) skip the import of any field that's a copyField destination by default, unless a configuration is present that restores the old behavior. The information about which fields are copyField destinations *is* available to those classes, so it would probably be a very easy change. There's not really a STRONG need for that new feature ... if you store both the source and destination fields, then you are storing exactly the same information twice, which is wasteful and increases resource requirements. Most applications that use Solr have at least surface knowledge of the schema, which should make it possible for the application writer to just pull the information from the source field. It seems that your application may not have that knowledge, though. Thanks, Shawn
