chore: compute event statistics using IdentifiableObjectManager DHIS2-17638 #17950
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Big picture
Tracker has multiple services for each entity like tracked entity, enrollment and event. One is in dhis-api and one in dhis-service-tracker. Our goal is to provide one API (service) per entity that is part of the tracker domain/team.
Trackers architecture splits read/write into exporter services and an importer. So if you want to get data you use an exporter. If you want to insert, update or delete you have to go through the importer. Only then can we ensure integrity of tracker data.
Another goal is that code that provides tracker functionality and is thus owned by the tracker team lives in ideally one maven module (We can settle on a name later on maybe
dhis-service-tracker
ordhis-tracker
).This is a big task that we are going to implement in many small steps.
This PR
There are a couple of issues with how the event/data value statistics are computed in the backend and shown in the data management app. There is a lengthy discussion on it in https://dhis2.slack.com/archives/CPGUFVC56/p1719906006918859. We could not settle on a way forward. We will discuss this in a dedicated meeting.
This PR keeps the behavior as is while getting us closer to our big picture described above. We can/will adapt once we come to an agreement with the platform team.
The logic of computing the last updated dates is extracted from
dhis2-core/dhis-2/dhis-services/dhis-service-core/src/main/java/org/hisp/dhis/program/DefaultEventService.java
Lines 97 to 100 in 51d18bd
(It is also the same for the data value counts)
The query that was previously part of our dhis-service-core HibernateEventStore
dhis2-core/dhis-2/dhis-services/dhis-service-core/src/main/java/org/hisp/dhis/program/hibernate/HibernateEventStore.java
Lines 76 to 84 in 51d18bd
is replaced by
dhis2-core/dhis-2/dhis-services/dhis-service-core/src/main/java/org/hisp/dhis/common/hibernate/HibernateIdentifiableObjectStore.java
Lines 633 to 644 in 1be8198