Maybe copy fields should be refactored to happen in a new, core, update
processor, so there is nothing special/awkward about them? It seems they fit
as part of what an update processor is all about, augmenting/modifying incoming
documents.
Erik
On Feb 23, 2011, at 04:40 , Jan Høydahl wrote:
> This is how I've got it:
>
> A document first passes through the UpdateChain (processors), which is
> document centric.
> Then copyFields are processed
> And finally the analysis in fieldTypes are processed
>
> So you cannot use <copyField> before UpdateProcessors nor after Analysis :(
>
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com
>
> On 23. feb. 2011, at 09.45, Markus Jelsma wrote:
>
>> You are right, i misread. Fields a copied first, then analyzed and then
>> behave
>> like other fields and pass the same way through the update processor.
>>
>> Cheers,
>>
>>> Markus,
>>>
>>> I searched but I couldn't find a definite answer, so I posted this
>>> question.
>>> The article you quoted talks about implementing a copyField-like operation
>>> using UpdateProcessor. It doesn't talk about relationship between
>>> the copyField operation proper and UpdateProcessors.
>>>
>>> Kuro
>>>
>>> On 2/22/11 3:00 PM, "Markus Jelsma" <markus.jel...@openindex.io> wrote:
>>>> Yes. But did you actually search the mailing list or Solr's wiki? I guess
>>>> not.
>>>>
>>>> Here it is:
>>>> http://wiki.apache.org/solr/UpdateRequestProcessor
>>>>
>>>>> Can fields created by copyField instructions be processed by
>>>>> UpdateProcessors?
>>>>> Or only raw input fields can?
>>>>>
>>>>> So far my experiment is suggesting the latter.
>>>>>
>>>>> ----
>>>>> T. "Kuro" Kurosaka
>
