So, if I'll be using Solr, what's the right strategy? Is it possible to redefine SolrDocument class through configuration? If not, would it be safe to inject these properties through Aspects while maintaining the whole framework intact and in workable condition? (eg, if at some point for some reason the field is cross checked with content of the index, which won't work if I'm injecting field from the DB, or smth like that...)
Vlad -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Yonik Seeley Sent: Sunday, November 05, 2006 9:36 AM To: java-user@lucene.apache.org Subject: Re: injecting fields looked up from DB at the runtime - Solr/Lucene question On 11/5/06, Vladimir Olenin <[EMAIL PROTECTED]> wrote: > - when the Hits objects are returned from IndexSearcher (as a result of some search), 'inject' 'info' fields into the 'Hit' objects at runtime by looking the values up in the DB. The main purpose is to avoid storing 'info' fields in the index as 'stored' fields. Yes, I've considered doing that at the Solr layer... adding something like a subclassable SolrDocument. An implementation could add other fields by retrieving them from a database. Upsides: simpler clients that don't need to understand where stored fields are coming from. Downsides: you tie yourself to a database (another thing to worry about in an environment where you need HA). -Yonik http://incubator.apache.org/solr Solr, the open-source Lucene search server --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
