summaryrefslogtreecommitdiff
path: root/doc/api/issues.md
diff options
context:
space:
mode:
authorRémy Coutable <remy@rymai.me>2016-06-23 15:02:10 +0000
committerRémy Coutable <remy@rymai.me>2016-06-23 15:02:10 +0000
commit26b957771974aee4457af5edf389509eb1ac80e7 (patch)
tree5d260ede73d63ba4ea462ae45f7d482c2e64e1de /doc/api/issues.md
parent110b2759c0c74d7bc85785ab481ff902cd7014d0 (diff)
parentd7a5a28c53c3af710ceb8ef4867ea61af7462903 (diff)
downloadgitlab-ce-26b957771974aee4457af5edf389509eb1ac80e7.tar.gz
Merge branch '18915-pagination-with-priority-sort-repeats-results' into 'master'
Fix pagination on sorts with lots of ties ## What does this MR do? Fixes #18915. As we only order by the sorted column, we don't have any tie-breaker. Some orderings, like priority and weight, have lots of ties, so you can see duplicate results as you page through. (Timestamp columns are less susceptible to this.) ## Are there points in the code the reviewer needs to double check? I just picked `id DESC`, this could as easily be `id ASC`. ## Why was this MR needed? Postgres and MySQL don't guarantee that pagination with `LIMIT` and `OFFSET` will work as expected if the ordering isn't unique. From the Postgres docs: > When using `LIMIT`, it is important to use an `ORDER BY` clause that > constrains the result rows into a unique order. Otherwise you will get > an unpredictable subset of the query's rows Before: [1] pry(main)> issues = 1.upto(Issue.count).map { |i| Issue.sort('priority').page(i).per(1).map(&:id) }.flatten [2] pry(main)> issues.count => 81 [3] pry(main)> issues.uniq.count => 42 After: [1] pry(main)> issues = 1.upto(Issue.count).map { |i| Issue.sort('priority').page(i).per(1).map(&:id) }.flatten [2] pry(main)> issues.count => 81 [3] pry(main)> issues.uniq.count => 81 See merge request !4878
Diffstat (limited to 'doc/api/issues.md')
0 files changed, 0 insertions, 0 deletions