What you are describing is pretty much what the original poster intends to do, as far as I understand.
Otis -- Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch ----- Original Message ---- > From: Norberto Meijome <[EMAIL PROTECTED]> > To: solr-user@lucene.apache.org > Sent: Thursday, June 12, 2008 9:13:39 AM > Subject: Re: Strategy for presenting fresh data > > On Wed, 11 Jun 2008 20:49:54 -0700 (PDT) > Otis Gospodnetic wrote: > > > Hi James, > > > > Yes, this makes sense. I've recommended doing the same to others before. > > It > would be good to have this be a part of Solr. There is one person (named > Jason) > working on adding more real-time search support to both Lucene and Solr. > > v. interesting - do you have any pointers handy on this? > > In the meantime, I had imagined that, although clumsy, federated search > could > be used for this purpose - posting the new documents to a group of servers > ('latest updates servers') with v limited amount of documents with v. fast > "reload / refresh" times, and sending them again (on a work queue, possibly), > to > the 'core servers'. Regularly cleaning the 'latest updates servers' of the > already posted documents to 'core servers' would keep them lean... of > course, > this approach sucks compared to a proper solution like what James is > suggesting > :) > > B > _________________________ > {Beto|Norberto|Numard} Meijome > > "Ugly programs are like ugly suspension bridges: they're much more liable to > collapse than pretty ones, because the way humans (especially > engineer-humans) > perceive beauty is intimately related to our ability to process and > understand > complexity. A language that makes it hard to write elegant code makes it hard > to > write good code." > Eric Raymond > > I speak for myself, not my employer. Contents may be hot. Slippery when wet. > Reading disclaimers makes you go blind. Writing them is worse. You have been > Warned.
