Phanindra.
1. I had no such need , the index was built from scratch. 2. Yes , I created a new URL and mapped it to the customized search handler. 3. The only thing I modified was the SearchHandler and specified that as the class for newly created URL in #2 above. Hope this helps. On Mon, Jun 9, 2014 at 12:22 AM, Phanindra R <phani...@gmail.com> wrote: > Thanks for the reply Meraj. It'd be great if you could share info on > following as well. > > 1) Did you have to load any stuff from database? How did you do that? > > 2) Did you create new urls and map them to your custom handlers? > > 3) Did you declare any custom object types in the solr-config.xml i.e. > other than <searchComponent>, <queryParser>, etc. > > > On Sun, Jun 8, 2014 at 7:42 PM, Meraj A. Khan <mera...@gmail.com> wrote: > > > I hane gone with approach #2 to avoid latency issues as well, > specifically > > for spellcheck related functionality.I have not gone onto to SolrCloud > yet > > ,so I cannot comment on the distributed search part. > > On Jun 8, 2014 10:38 PM, "Phanindra R" <phani...@gmail.com> wrote: > > > > > Hi, > > > > > > We have decided to migrate from Lucene 3.x to latest Solr. A lot of > > > architectural discussions are going on. There are two possible > > approaches. > > > > > > Please note that our customer-facing app (or any client) and Search are > > > hosted on different machines. > > > > > > *1) Have a clean architecture* > > > - Solr takes care of customized search only. > > > > > > - We certainly have to override some filtering, scoring,etc. > > > > > > - There will be an intermediary search-app that > > > > > > - receives queries > > > - does a/b testing assignments, and other non-search stuff. > > > - does query expansion / rewriting (to avoid every Solr shard > doing > > > that) > > > - transforms query into Solr syntax and uses Solr's http API to > > > consume it. > > > - returns the response to customer-facing app or whatever the > > client > > > is. > > > > > > The problem with this approach is the additional layer and the > latency > > > between search-app and solr. The client of search has to make an API > > call, > > > across the network, to the intermediary search-app which in turns makes > > > another Http API call to Solr. > > > > > > *2) Customize Solr to the full extent* > > > > > > - Do all the crazy stuff within Solr. > > > - We can literally create a new url and register a handler class to > > > process that. With some limitations, we should be able to do almost > > > anything. > > > > > > The benefit of this approach is that it obviates the additional > > layer > > > and the latency. However, I see a lot of long-term problems like hard > to > > > upgrade Solr's version, Dev flexibility (usage of Spring, Hib, etc.). > > > > > > How about a distributed search? Where do above approaches stand? > > > > > > I understand that this is a subjective question. It'd be helpful if you > > > could share your thoughts and experiences. > > > > > > Thanks. > > > > > >
