Thanks, Tim, you've confirmed what I've suspected. I appreciate the reality check. :)
Phil On Tue, Feb 26, 2013 at 11:49 AM, Timothy Potter <thelabd...@gmail.com> wrote: > Hi Phil, > > It seems like you're treating Solr like a library and not a service. > Solr is a service that abstracts away all the lower-level Lucene work > like working with hits. If you want to work with hits, then you're > better to stay with Lucene. > > So yes, you're going to need to change your client application code to > work with Solr but all the work of converting hits into documents, > cache management, IndexReader management, etc. is all done for you by > Solr. With Solr, your focus is on constructing queries and processing > responses. The mechanics of searching with Lucene are hidden. Thus, > I'd say the amount client code to support search in your application > will be reduced significantly using Solr. > > Cheers, > Tim > > On Tue, Feb 26, 2013 at 9:30 AM, Philip Durbin <philipdur...@gmail.com> wrote: >> I'm exploring a switch from Lucene to Solr in a Java EE webapp. >> >> We have a method called getHitIds() that accepts as a parameter a >> Lucene "Query" object: >> >> http://lucene.apache.org/core/old_versioned_docs/versions/3_0_0/api/core/org/apache/lucene/search/Query.html >> >> My IDE is telling me I can't simply pass it a "SolrQuery" object instead: >> >> http://lucene.apache.org/solr/4_1_0/solr-solrj/org/apache/solr/client/solrj/SolrQuery.html >> >> ... so I'm finding myself significantly rewriting and changing how >> search works just to get something working in Solr: >> >> change getHitIds() param from Query to SolrQuery >> https://github.com/IQSS/dvn/commit/688bbe6 >> >> I'd rather just keep the existing business logic in place, if >> possible. That is to say, I'd like getHitIds() to return the same list >> of IDs, but with Solr instead of Lucene. >> >> If someone could point me in the right direction, I would really appreciate >> it. >> >> Thanks, >> >> Phil >> >> -- >> http://greptilian.com
