Currently we are not using SolrJ but are simply interacting with solr with json over http, this will change in a couple of months but currently not there. As of now we are putting all the logic in query building, using it to query solr and then passing on the json returned by it to front end. I know this is not the ideal approach, but that's what we have at the moment. Hence need a way of deterministically order the result set provided they match other search criteria.
On Tue, Jun 17, 2014 at 10:28 PM, Chris Hostetter <hossman_luc...@fucit.org> wrote: > > All index wide statistics (like the docFreq of each term) are over the > entire index, which includes deleted docs -- because it's an *inverted* > index, it's not feasible to update those statistics to account for deleted > docs (that would basically kill all the performance advantages thatcome > from having an inverted index. > > > : uniqueField:(id1 ^ weight1 OR id2 ^ weight2 ..... OR idN ^ weightN) > : where weight1 > weight2 > ........ > weightN > : > : But the result is not in the desired order. On debugging the query we've > > if you are requesting a small number of docs, and all the docs you are > requesting are returned in a single request, why do you care what order > they are in? why not just put them in hte order you want on the client. > > That would not only make your solr request simpler, but would almost > certainly be a bit *faster* since you could sort exactly as you wnated w/o > needing to compute a complex score that you don't actaully care about. > > > > -Hoss > http://www.lucidworks.com/ > -- Thanks & Regards, Apoorva
