In our case, we just store a database id and do a secondary db query when displaying the results. This is handy and leads to a more centralised architecture when you need to display properties of a domain object which you don't index/search.
On 28 October 2010 05:02, kenf_nc <ken.fos...@realestate.com> wrote: > > Interesting wiki link, I hadn't seen that table before. > > And to answer your specific question about indexed=true, stored=false, this > is most often done when you are using analyzers/tokenizers on your field. > This field is for search only, you would never retrieve it's contents for > display. It may in fact be an amalgam of several fields into one 'content' > field. You have your display copy stored in another field marked > indexed=false, stored=true and optionally compressed. I also have simple > string fields set to lowercase so searching is case-insensitive, and have a > duplicate field where the string is normal case. the first one is > indexed/not stored, the second is stored/not indexed. > -- > View this message in context: > http://lucene.472066.n3.nabble.com/Stored-or-indexed-tp1782805p1784315.html > Sent from the Solr - User mailing list archive at Nabble.com. >
