View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0021044||mantisbt||performance||public||2016-06-02 17:39||2017-01-31 04:02|
|Priority||normal||Severity||minor||Reproducibility||have not tried|
|Target Version||2.1.0||Fixed in Version||2.1.0|
|Summary||0021044: my view page, $t_hide_status_default consitency|
Looking at query times for my_view_page, all predefined filters use $t_hide_status_default, except for the "last updated" filter, which defaults to META_FILTER_NONE
I don't know if there is a strong reason to not follow all the filter and comply with that option.
By applying the $t_hide_status_default option to this query, much less rows are used, the query is optimized by the table index, and execution time greatly improves.
In my test instance with 150k issues:
|Tags||No tags attached.|
We may want to still show closed status, for the 'last updated' filter, precisely to show recent issues that has been closed.
In that case, another option to limit that query can be to query only issues recently updated "in the last N days". That will keep the query to a small size, and short execution time.
What do you think?
If you can find another way to achieve this with better performance, it would be great, but as you mentioned I'm not sure it can be achieved with the current filter API.
An alternative could be not to display the total number of issues (but that's a loss in functionality).
Actually,the total number of issues, as it's showed for the 'last updated' filter does not make any sense.
12k is the total number of issues in the mantisbt project
I know, but the total number displayed is in the context of the filter:
This one does not match the filter semantics:
Adding the feature to filter by last_update field would make for a proper solution, and that is also a quite popular request...
track as included in PR 862
"recently modified" view has been modified to use a filter by last update date.
|2016-06-02 17:39||cproensa||New Issue|
|2016-06-02 17:40||cproensa||Description Updated||View Revisions|
|2016-06-02 17:42||cproensa||Description Updated||View Revisions|
|2016-06-02 17:45||cproensa||Relationship added||related to 0021038|
|2016-06-02 17:54||cproensa||Note Added: 0053253|
|2016-06-03 06:11||dregad||Note Added: 0053257|
|2016-06-03 06:30||cproensa||Note Added: 0053258|
|2016-06-03 08:08||dregad||Note Added: 0053259|
|2016-06-03 08:13||cproensa||Note Added: 0053260|
|2016-06-03 15:18||cproensa||Note Added: 0053263|
|2016-06-20 09:19||atrol||Relationship deleted||related to 0021038|
|2016-06-20 09:20||atrol||Relationship added||has duplicate 0021038|
|2016-10-19 12:16||cproensa||Relationship added||related to 0006823|
|2016-11-06 12:30||cproensa||Assigned To||=> cproensa|
|2016-11-06 12:30||cproensa||Status||new => assigned|
|2016-11-06 12:31||cproensa||Note Added: 0054445|
|2016-11-20 15:29||cproensa||Relationship added||child of 0021827|
|2017-01-14 17:23||cproensa||Status||assigned => resolved|
|2017-01-14 17:23||cproensa||Resolution||open => fixed|
|2017-01-14 17:23||cproensa||Fixed in Version||=> 2.1.0|
|2017-01-14 17:23||cproensa||Note Added: 0055123|
|2017-01-14 17:23||cproensa||Target Version||=> 2.1.0|
|2017-01-14 18:01||cproensa||Relationship added||child of 0021935|
|2017-01-14 18:02||cproensa||Relationship deleted||child of 0021827|
|2017-01-31 04:02||vboctor||Status||resolved => closed|