bq: we don't want to use either the primary key or the record's update date as the tie-breaker, as it may introduce an new bias into the ranking algorithm
Are you thinking of adding something to your main clause to force this? If so, why not just use sorting by adding a sort clause like: &sort=score desc, datefield desc I think you'll get what you want... Or I'm misunderstanding... Best Erick On Tue, Feb 26, 2013 at 3:22 PM, Gregg Donovan <gregg...@gmail.com> wrote: > We're running into an issue when comparing Solr results for the same > query across different clusters . When we don't sort by anything other than > "score desc" we'll see inconsistent tie-breaking across different clusters. > When we add an explicit secondary sort by the primary key, results are the > same across clusters. I believe this is to be expected and that Solr/Lucene > will revert to sorting by doc_id in the case of tied scores if no secondary > sort is specified. Our indexing process is random enough in how it feeds > documents to the indexer that we see different primary key ordering in the > index in different clusters. > > In our case, we don't want to use either the primary key or the record's > update date as the tie-breaker, as it may introduce an new bias into the > ranking algorithm. I'm considering adding a secondary sort by a hash of the > primary key, as this will be consistent across clusters but randomly > distributed. > > Questions: > > --Has anyone else encountered this problem? If so, how have you solved it? > > --What's the best way to hook this in? A copyField plus a custom FieldType? > > Thanks. > > --Gregg >
