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. Best, Erick On Tue, Mar 31, 2015 at 6:47 AM, Toke Eskildsen <t...@statsbiblioteket.dk> wrote: > Steven White [swhite4...@gmail.com] 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
