cahining copyFields

[Batzenmann <ax...@freiheit.com>]

Hi,

I recently discovered that the copyFields directive exclusively works for
copying fields from the input doc to the indexed/stored doc.
I'd like to be able to do the following:

excerpt from schema.xml:
   <field name="a" type="grandVoodoo" indexed="true" stored="true"
multiValue="true"/>
   <field name="b" type="trimmedString" indexed="true" stored="true"
multiValue="true"/>

   <copyField source="someInputField1" dest="a" />
   <copyField source="someInputField2" dest="a" />
   <copyField source="someInputField3" dest="a" />
   <copyField source="a" dest="b" />
   <copyField source="someInputField4" dest="b" />

where only "someInputField1..4" is specified in the doc in the update
command. The goal is not to have to redundantly specify the whole
analyzer/copyFields voodoo for the "b" field.

Am I correct that this is currently only possible by specifying:
   <field name="a" type="grandVoodoo" indexed="true" stored="true"
multiValue="true"/>
   <field name="b" type="trimmedString" indexed="true" stored="true"
multiValue="true"/>

   <copyField source="someInputField1" dest="a" />
   <copyField source="someInputField2" dest="a" />
   <copyField source="someInputField3" dest="a" />

   <copyField source="someInputField1" dest="b" />
   <copyField source="someInputField2" dest="b" />
   <copyField source="someInputField3" dest="b" />
   <copyField source="someInputField4" dest="b" />

where I also have to decide wether to analyze all input on "b" with the
trimmedString or the grandVoodoo analyzer..

thanks, Axel

-- 
View this message in context: http://www.nabble.com/cahining-copyFields-tp19839265p19839265.html
Sent from the Solr - User mailing list archive at Nabble.com.

Re: cahining copyFields

[Batzenmann <ax...@freiheit.com>]

Batzenmann wrote:
> 
> cahining
> 

and meant: 'chaining' -

sry for spamming,
Axel
-- 
View this message in context: http://www.nabble.com/cahining-copyFields-tp19839265p19839530.html
Sent from the Solr - User mailing list archive at Nabble.com.

Re: cahining copyFields

[Axel Tetzlaff <ax...@freiheit.com>]

hossman wrote:
> 
> it ensures the schema creator must clearly thinks through exactly what 
> should be copied where -- otherwise you might have an existing mappings 
> of x->z and y->z that you don't consider/remember when adding a->x (or 
> worse: a->x and a->y)
> 

Hmm, I can see your reasoning here.


hossman wrote:
> 
> this part of yourquestion doesn't make sense to me ... 
> 

I'll try to give a more substantial example(which I should properbly have
done in the first plac): We're searching for products and got a (short)
title and (long) description as well as brands, shops etc.
All the small fields are copied into a catch-all field 'text' which involves
verstatile analysis. The description is not copied (to reduce the noise). To
be able to switch at runtime to a field where also the description is
considered, we thought it'd be a good idea to copy the content of 'text'
along with the description into an extended catch-all field.
This would just need a very basic, i.e. WhiteSpace-, tokenizer and no
further filters.

Of course this functionality is not vitally important, but I still wanted to
make sure I'm not missing s.th. obvious here. I guess making the copyFields
recursive does rise quite some questions, and doesn't really justify the
hassle, just for not having to copy the 10 lines ;-)

Thx for your explanation,
Axel


-- 
View this message in context: http://www.nabble.com/cahining-copyFields-tp19839265p19846541.html
Sent from the Solr - User mailing list archive at Nabble.com.

Re: cahining copyFields

[Chris Hostetter <ho...@fucit.org>]

: I recently discovered that the copyFields directive exclusively works for
: copying fields from the input doc to the indexed/stored doc.

correct.  you have to explicitly list the mappings, it's not recursive (as 
i recall this was done partially because it was easier, but also because 
it ensures the schema creator must clearly thinks through exactly what 
should be copied where -- otherwise you might have an existing mappings 
of x->z and y->z that you don't consider/remember when adding a->x (or 
worse: a->x and a->y)

: where I also have to decide wether to analyze all input on "b" with the
: trimmedString or the grandVoodoo analyzer..

this part of yourquestion doesn't make sense to me ... independent of 
anything copyField does, the analysis is specific to the final field, a 
value in b won't be analyzed any differently if it was originally 
specified for b, or copied to b from a, or if copied from b to c.




-Hoss