Minor pedantic point (I like those). "equiv to the order in which they were added to the index" depends on the merge policy. That was true when Yonik wrote it, but other merge policies added since then may or may not preserve insertion order in terms of the internal Lucene ID. The default TieredMergePolicy, for instance does _not_.
So TieredMergePolicy in SolrCloud can lead to "interesting" situations. The internal lucene doc ID of two particular docs on two replicas of the _same_ shard are not even guaranteed to be in the same relation to each other. On replica 1 doc1 could have id 23 and doc2 could have id 50, but on replica2 they could be 66 and 19 respectively. Which means that Jimi is absolutely correct in the only way to make predictions about tied sorts is to specify a secondary sort. If you wanted to, for instance, preserve the insertion order you'd add a counter to each doc and use that counter as a secondary sort. Best, Erick On Tue, Jan 10, 2017 at 5:46 AM, <jimi.hulleg...@svensktnaringsliv.se> wrote: > Hi Kshitij, > > Quoting Yonik, the creator of solr: > > "Ties are the same as in lucene... internal docid (equiv to the order in > which they were added to the index)." > > Also, you can have multiple sort clauses, where score can be the first one. > Like sort=score DESC, publishDate DESC. But I think the recommended approach > is to use boosting on date (etc) to effect the score instead. > > Hope this helps. > /Jimi > > -----Original Message----- > From: kshitij tyagi [mailto:kshitij.shopcl...@gmail.com] > Sent: Tuesday, January 10, 2017 5:11 PM > To: solr-user@lucene.apache.org > Subject: Same score listing order > > Hi, > > I need to understand what is the order of listing the documents from query in > case there is same score for all documents. > > Regards, > Kshitij
