Sorry Erick, I completely agree with you, I didn;'t specify in details what I was thinking :
" copy fields must not be executed if the updated field is not a source field ( in a copy field couple) " furthermore I agree again with you, copy field should try to give a different analysis to the new field, simply changing the name would be matter of field analysis. Nothing required at indexing time ! Cheers 2015-07-15 16:26 GMT+01:00 Erick Erickson <erickerick...@gmail.com>: > 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 > > > -- -------------------------- Benedetti Alessandro Visiting card - http://about.me/alessandro_benedetti Blog - http://alexbenedetti.blogspot.co.uk "Tyger, tyger burning bright In the forests of the night, What immortal hand or eye Could frame thy fearful symmetry?" William Blake - Songs of Experience -1794 England
