lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Hostetter <hossman_luc...@fucit.org>
Subject Re: correct use of copyFields in schema.xml
Date Thu, 18 Dec 2008 07:26:26 GMT

First...

: In-Reply-To: <21051199.post@talk.nabble.com>
: Subject: correct use of copyFields in schema.xml

http://people.apache.org/~hossman/#threadhijack
Thread Hijacking on Mailing Lists

When starting a new discussion on a mailing list, please do not reply to 
an existing message, instead start a fresh email.  Even if you change the 
subject line of your email, other mail headers still track which thread 
you replied to and your question is "hidden" in that thread and gets less 
attention.   It makes following discussions in the mailing list archives 
particularly difficult.
See Also:  http://en.wikipedia.org/wiki/Thread_hijacking


Second...

: Reviewing the various examples that comes with Solr I cant make up
: mind wether the copyFields element should be nested within the
: fields element or not. The http://wiki.apache.org/solr/SchemaXml
: documentation makes it clear it should be outside, yet a number
: of examples have it nested.

The copy field parsing code for schema.xml is very forgiving, it should 
work to have them almost anywhere, but i would suggest you keep them all 
in one group, it tends to be easier to make sense of what is getting 
copied where when they are all clustered.

: IMHO, being able to nest copyFields inside fields makes for 
: more self documenting code!

it's subjective -- but as i said, prone to confusion: If you mix the 
directives do you keep the 
copyField statements near the source <field> or near the destination 
<field>? .. it's just as important to know where data is coming from as 
where it's going to.  what if the source is a wildcard pattern that 
matches multiple fields?

if they're all in one place, then at least it's easy to go to one 
place to view them all at once, without having to hunt arround for a 
directive that might be affecting a field but isn't near it (because it's 
near the *other* field it refrences)



-Hoss


Mime
View raw message