| Issue Number | 647 |
|---|---|
| Summary | Article Search Page - Modification Date not preforming well |
| Created | 2022-11-28 10:58:43 |
| Issue Type | Bug |
| Submitted By | Boggess, Cynthia (NIH/NCI) [C] |
| Assigned To | Kline, Bob (NIH/NCI) [C] |
| Status | Closed |
| Resolved | 2022-11-30 11:09:15 |
| Resolution | Fixed |
| Path | /home/bkline/backups/jira/oceebms/issue.333259 |
Modification Date Range search is not performing well. When searched by itself or in combination it goes into an endless churn. It has not produced an error message yet but I have only let it churn for 2-4 minutes. Note: this feature is slow in PROD as well but will produce a result.
I have completely rewritten the query for searches using the Modification Date Range fields, bypassing the Entity Query API and directly using SQL statements (or as direct as it gets when using the Database API) instead. Such searches are still slow but at least they complete. The semantics for these fields are very complicated. The software is being asked to find articles which meet ANY of the following criteria:
the article has at least one state which was assigned during the specified date range
the article has at least one state for which a new comment was added during the specified date range
the article has at least one tag which was assigned to the article during the specified date range
the article has at least one tag assigned to the article for which a new comment was added during the specified date range
the article has at least one topic to which a tag was assigned during the specified date range
the article has at least one topic with a tag for which a new comment was added during the specified date range
At some point in the future, it might be worth while to revisit these requirements, asking whether making the software check for all of these possibilities is essential to the business needs behind these fields. Perhaps we could reduce the number of places the software has to look. Or maybe the field could be split into more than one date range, looking in different places separately, and cautioning users against combining them in the same search.
First off this is now providing results...slow but the search gets completed. I tried it alone and in combination with other search criteria.
I am pretty sure that Jeff and I may be the only people using this feature. I use it to identify citations where a mistake may have been made during reviewing. I usually limit to board or a summary topic. And I have always wanted this to be user specific, but I don't know if that would complicate things more or not. But yes, at some point I need to think about how I am using this and see if we can simplify or focus it.
Just now a search for citations modified on 1/6/2023 in ebms4 took 4min 32sec and produced an accurate result. As I mentioned earlier this is not a feature that is used often but is very useful for the librarians. As long as it does not start timing out or produce errors, we are good for now. I think we may want to move this ticket to the backlog and as Bob suggested, revisit the requirements in a later sprint. Any thoughts?
That sounds like the right approach.
Verified on QA. Thanks!
Elapsed: 0:00:00.000546