fix: Only use occurreddate to filter events in exporter [DHIS2-17732]

[enricocolasante]

We were applying some magic between occurreddate and scheduleddate in events and it was creating a performance issue and some odd behavior.

Performance issue

• In the query to filter occurreddate, if there was a null value, then the one in scheduledate was used. This behavior was preventing the index on occurreddate to be used by the query planner slowing down the query performance.

Odd behavior

• In the API the parameters occurredAfter and occurredBefore are used to filter the occurreddate but because of the logic that we had in the query, null values of occurreddate could be part of the result.
• In the importer we were populating scheduleddate with occurreddate value if the former one was null. This wrongly appears as if the event was once scheduled and occurred in the same point in time. If an event was never scheduled, it should have a null scheduleddate.

These corner cases were not tested so no test is breaking. The feature itself is already properly tested in https://github.com/dhis2/dhis2-core/blob/master/dhis-2/dhis-test-integration/src/test/java/org/hisp/dhis/tracker/export/event/EventExporterTest.java

[teleivo]

Can you post some numbers on how that affects performance (and or explain analyze changes)?

[enricocolasante]

Can you post some numbers on how that affects performance (and or explain analyze changes)?

In some implementations it passed from 95 seconds to 2 seconds, there is more info in the thread https://dhis2.atlassian.net/browse/DHIS2-17732?focusedCommentId=205282

The changes affected performance because before the OR clause was forcing the planner to scan the whole event table, after removing it, the index can be used instead and there is no need of the full scan of the table.

[sonarcloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[muilpp]

nice!