Vote #79513
完了Issues in paginated views may be lost because sorting criteria are not unique
0%
説明
This is a problem that the issue that should be present is not displayed on the issues/index.
The same problem may exist even at index other than issues/index.
This problem occurs when using PostgreSQL.
If you use only non-unique fields such as trackers or categories as the sorting criteria, there is a possibility that some issues will not be displayed on pagination views.
This phenomenon is described in the document of PostgreSQL. (As a specification rather than a bug)
https://www.postgresql.org/docs/8.3/static/queries-limit.html
Questions about the same problem:
https://stackoverflow.com/questions/13580826/postgresql-repeating-rows-from-limit-offset
I attached file is the test I wrote to reproduce this problem.
If you are using PostgreSQL, that test will fail. ( Non-paginated issue ids and paginated issue ids should be the same. )
Failure: --- expected +++ actual @@ -1 +1 @@ -[2, 12, 11, 8, 7, 5, 3, 1, 13] # Non-paginated issue ids +[11, 12, 12, 7, 7, 5, 3, 1, 13] # Paginated issue ids
journals
I wrote a patch to solve this problem.
I fixed to add unique fields (ex: issues.id, time_entries.id) as sort criteria.
--------------------------------------------------------------------------------
Setting target version to 4.1.0.
--------------------------------------------------------------------------------
> <code>order_option += ['issues.id ASC'] unless order_option.include?("issues.id DESC") || order_option.include?("issues.id ASC")</code>
Is it ok to use `issues.id ASC` as a default implicit order?
<code>IssueQuery#default_sort_criteria</code> uses <code>issues.id DESC</code>.
(Pair-reviewed with "maimai77":https://github.com/maimai77)
--------------------------------------------------------------------------------
vzvu 3k6k wrote:
> > <code>order_option += ['issues.id ASC'] unless order_option.include?("issues.id DESC") || order_option.include?("issues.id ASC")</code>
>
> Is it ok to use `issues.id ASC` as a default implicit order?
>
> <code>IssueQuery#default_sort_criteria</code> uses <code>issues.id DESC</code>.
>
> (Pair-reviewed with "maimai77":https://github.com/maimai77)
Thank you for reviewing fix-29581.patch.
As you point out, it seems natural to use the same sort criteria as IssueQuery#default_sort_criteria.
I have attached the file to fixed patch.
--------------------------------------------------------------------------------
Thank you for your response! Your v2 patch looks good to me.
--------------------------------------------------------------------------------
> 'issues.id DESC'
Is it OK to write table name of the Issue model directly?
In app/models/issue_query.rb, It seems code like following is more preferable.
<pre>
"#{Issue.table_name}.id DESC"
</pre>
--------------------------------------------------------------------------------
Seiei Miyagi wrote:
> > 'issues.id DESC'
>
> Is it OK to write table name of the Issue model directly?
> In app/models/issue_query.rb, It seems code like following is more preferable.
>
> [...]
Thank you for pointing it out.
I changed the way of writing table names.
--------------------------------------------------------------------------------
Patch committed, thanks.
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
related_issues
relates,Closed,32737,Duplicate sort keys for issue query cause SQL error with SQL Server
duplicates,Closed,31924,Paging misses some entries