On 6/22/06, Yonik Seeley <[EMAIL PROTECTED]> wrote:
On 6/22/06, Mike Klaas <[EMAIL PROTECTED]> wrote:
> It uses term vectors, if present, to speed up highlighting (else the > stored field needs to be re-analyzed). Does your current code already handle the re-analyze case?
Yes, it grabs the correct analyzer from IndexSchema.
It does seem like it would be easier for clients to parse document associated data if it is included directly in the <doc> element. One way might be to create an extension point where Documents could be manipulated and fields could be added. This could also be useful for integrating with large stored fields that might not be kept in the index, but in a separate database instead. That brings up another point... the ability to highlight something that doesn't have termvectors stored, and doesn't have the field stored might be useful. The same interface used to add new fields above could potentially be used here as well.
Creating an external storage hook seems like a bit more than I am comfortable biting off (among other things, it seems like a major solr design decision). The ability to highlight arbitrary text is easy once solr has gotten hold of it, however. There also a matter of specifying an Analyzer for the highlighting. <>
> FieldType, and the only RequestHandler customization is the selection > of which fields to highlight. I'm not sure if this is really the property of a field. Another possibility is using init params in the request handler defined in solrconfig.xml, with the possibility of overriding them in a request.
True, though it seems nettlesome to have per-field highlighting customization using that strategy. Perhaps a distinction could be made between highlighting and summarizing, which are two rather different use cases. cheers, -MIke
