lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erick Erickson <>
Subject Re: What's the need for copyField> when you have "fq"
Date Tue, 31 Mar 2015 16:55:21 GMT
Yet a third is that <copyField> is often used when you want to treat
the same data different ways. For instance, consider a "title" field.
You might want to sort by title, but sorting on a tokenized field is
undefined so I might use a copyField from "title" to "title_sort" and
analyze the sort field with some kind of normalized sorting (including
lowercasing, removing leading articles, etc).

Another thing to consider is dynamic fields. You may not _know_ all
the fields up-front and putting them all in a single field to search
may make sense.

You're right though, if you want to construct entire clauses across
individual fields, you can do that explicitly or use edismax and
there's no need to copyField anything.


On Tue, Mar 31, 2015 at 6:47 AM, Toke Eskildsen <> wrote:
> Steven White [] wrote:
>> If I have 50 fields in a Solr doc and I index them without doing any
>> <copyField> to a catch-all-field called "all_text".  During search I use
>> "fq" to list all the 50 fields to search on.  Now how different is this
>> from not using "fq" and searching against my catch-all-field of "all_text"
>> using "q"?
> One potential use it to have the catch-all-field perform severe normalization to match
more queries but rank those extra matches lower than a direct hit in a specific field. The
same effect can be accomplished by having differently analyzed versions of the same logical
field: Having a single catch-all is just easy to do.
> Another reason can be performance: fq-matching against all fields is heavier than matching
against a few fields and the catch-all.
> - Toke Eskildsen

View raw message