> Is a new DocID generated everytime a doc with the same UniqueID is added to > the index? If so, then docID must be incremental and would look like > indexed_at ascending. What I see (and why it's a problem for me) is the > following.
Yes, Solr removes the old and inserts a new when updating an existing document. > > a search brings back the first 5 documents in a result set of say 60. The > score,titles are as follows (simulated) > 1) 6.5, Doc 1 > 2) 6.3, Doc 2 > 3) 4.7, Doc 3 > 4) 4.7, Doc 4 > 5) 4.7, Doc 5 > --- > 6) 4.7, Doc 6 > 7) 4.7, Doc 7 > 8) 4.4, Doc 8 > > If I query 6 times the results come back like that every time. However if I > change a field in Doc 4, a field that is not part of the search, it gets > the same score, but the results are now this. > 1) 6.5, Doc 1 > 2) 6.3, Doc 2 > 3) 4.7, Doc 3 > 4) 4.7, Doc 5 > 5) 4.7, Doc 6 > --- > 6) 4.7, Doc 7 > 7) 4.7, Doc 4 > 8) 4.4, Doc 8 The above scenario makes sense indeed. > > So, in a specific situation I'm looking at, a user sees 5 items on a UI > page, they click a button to 'favorite' document #4, I update Doc 4 and > (because it was architecturally better) I re-issue the search. So from the > users viewpoint they 'favorited' number 4 and it disappeared from their > screen. Not a good user experience. I agree. If you don't want this to happen you must ensure that the index order is never used in a search. > > If I could modify the secondary sort when score is the same then worse case > doc 4 would pop to the top of the users screen but not disappear. Better > would be to secondary sort on Title or some other fixed field that exists > on all documents. But, I would want the sort to be at the system level, I > dont' want the overhead of sorting every query I ever make. Well, sub-sorts must be used to avoid the index order being used for output. Maybe sorting on creation time (obviously not update time) as a final sort is allowed in our use case. It'll take some resources but if business requirements are as such then the resource penalty must be met or accepted. What do you mean by sorting on the system level? You need the overhead if you don't want the index order to reflect in your result set if the final sub-sort also results in duplicates. > > > > -- > View this message in context: > http://lucene.472066.n3.nabble.com/Result-order-when-score-is-the-same-tp2 > 816127p2817766.html Sent from the Solr - User mailing list archive at > Nabble.com.
