On Wed, Aug 27, 2008 at 7:47 PM, Jake Conk <[EMAIL PROTECTED]> wrote: > Thanks for the reply. Does that mean that if I were to edit the data > then the field it was copied to will not be updated?
You can't really "edit" a document in Lucene or Solr, really just overwrite an old document with an entirely new version. > I assume it does > get deleted if I delete the record right? I understand how it can make > searching simpler by copying fields to one but would that really make > it faster? How? Searching a single field for a term is faster than searching multiple fields for a term. That's really only one use case though... the other being to have a single stored field that is analyzed multiple different ways. -Yonik > Thanks, > - Jake > > On Wed, Aug 27, 2008 at 2:22 PM, Yonik Seeley <[EMAIL PROTECTED]> wrote: >> Jake, copyField exists to decouple document values (on the update >> size) from how they are indexed. >> >> From the example schema: >> <!-- copyField commands copy one field to another at the time a document >> is added to the index. It's used either to index the same >> field differently, >> or to add multiple fields to the same field for easier/faster >> searching. >> --> >> >> -Yonik >> >> On Wed, Aug 27, 2008 at 4:46 PM, Jake Conk <[EMAIL PROTECTED]> wrote: >>> Hello, >>> >>> I was wondering if there was an added advantage in using <copyField /> >>> to copy a string field to a text field? >>> >>> If the field is copied to a text field then why not just make the >>> field a text field and eliminate copying its data? >>> >>> If you are going to use full text searching on that field which you >>> cant do with string fields wouldn't it just make sense to keep it a >>> text field since it has the same abilities as a string field and more? >>> >>> ... Or is the reason because string fields have better performance on >>> matching exact strings than text fields? >>> >>> Thanks, >>> >>> - Jake >>> >> >
