Alfonso: Haven't worked with this myself, but could "field aliasing" handle your use-case _without_ the need for a copyField at all? See: https://issues.apache.org/jira/browse/SOLR-1205
Again I need to emphasize that I HAVE NOT worked with this so it may be a really bad suggestion. Or it may not apply. Or..... Alessandro: You wrote: "The simple solution should be to not execute any copy field instruction in an updatedDocument." I don't think that would work as then legitimate copyFields wouldn't be reflected. Say you had a copyField from A to B. Now you atomically update A. That update should be reflected in B... Best, Erick On Wed, Jul 15, 2015 at 8:19 AM, Shawn Heisey <apa...@elyograg.org> wrote: > 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 >
