Re: Preserving C++ and other weird tokens

Ach, sorry I didn't find this before posting! - Michael Yonik Seeley-2 wrote: http://search.lucidimagination.com/search/document/2d325f6178afc00a/how_to_search_for_c -Yonik http://www.lucidimagination.com -- View this message in context:

Re: Is kill -9 safe or not?

Thanks for the confirmation and reassurance! - Michael Yonik Seeley-2 wrote: On Fri, Aug 7, 2009 at 12:04 PM, Otis Gospodneticotis_gospodne...@yahoo.com wrote: Yonik, Uncommitted (as in solr uncommited) on unflushed? Solr uncommitted. Even if the docs hit the disk via a segment

Re: Modifying a stored field after analyzing it?

markrmiller wrote: Yonik's patch makes it so that you can supply the TokenStream straight to the field and still store an *independent* text value in a stored field. When building the Lucene Document, when adding the field, you would add the raw TokenStream and then use setValue to set

Re: Modifying a stored field after analyzing it?

Shalin Shekhar Mangar wrote: Can't you have two fields like this? f1 (indexed, not stored) - one two three four [METAINFO] oneprime twoprime threeprime fourprime f2 (not indexed, stored) - one two three four Perhaps I don't understand highlighting, but won't that prevent snippets

Re: Modifying a stored field after analyzing it?

markrmiller wrote: Coming soon. First step was here: http://issues.apache.org/jira/browse/LUCENE-1699 Trunk doesn't have that version of Lucene yet though (I believe thats still the case). Replacing the RunUpdateProcessor give you full control of the Lucene document creation. Is

Re: Modifying a stored field after analyzing it?

markrmiller wrote: When you specify a custom UpdateProcessor chain, you will normally make the RunUpdateProcessor the last processor in the chain, as it will add the doc to Solr. Rather than using the built in RunUpdateProcessor though, you could simply specify your own UpdateProcessor