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:
http://www.nabble.com/Preserving-%22C%2B
Thanks for the confirmation and reassurance! - Michael
Yonik Seeley-2 wrote:
>
> On Fri, Aug 7, 2009 at 12:04 PM, Otis
> Gospodnetic wrote:
>> Yonik,
>>
>> Uncommitted (as in solr un"commit"ed) on unflushed?
>
> Solr uncommitted. Even if the docs hit the disk via a segment flush,
> they aren'
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 sni
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.
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 UpdateProce
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 s
