feat: Add not-null constraint for column trackedentitytypeid in trackedentity table [DHIS2-15066]

[zubaira]

DHIS2-15066

• PR checks for NULL values in the trackedentitytypeid column of the trackedentity table, updates missing values based on the programid from the enrollment table, and then safely alters the column to NOT NULL if no inconsistencies are found.
• Moreover it changes createTrackedEntity method signature in TestBase.java to make sure user provide a non-null TrackedEntityType to TrackedEntity.

[enricocolasante]

We are having discussion about the approach here (that is the same for organisationunitid column in event and enrollment) and we are trying to avoid to create dummy data that are likely entering the DB and never being deleted.

I think we should fix this the same way in all the places where we found it.
As soon as we have a strategy we should go back to this PR and see what we should do.

[enricocolasante]

setTrackedEntityType

[zubaira]

fixed

[enricocolasante]

Here we shouldn't update any record.
We should only apply the constraint.
The we can suggest such a script in the migration notes

[zubaira]

there is a lower possibility of errors if we handle the task ourselves rather than leaving it to the user. Therefore, we should aim to complete as much of the migration process as possible and leave as little as necessary for the user to manage.

[enricocolasante]

For this kind of process that deal with data we need to be much more clear with the user and very very careful on any step.
Here you are fixing inconsistent data in a correct way, getting the tracked entity type from any underling enrollment but this is not the only issue that could happen and this SQL is running in a transaction (even without specifically start the transaction as done here, flyway will wrap this in a transaction), so if there is any inconsistent data that cannot be fixed in the way you provided, no data is fixed.
Than the user is sent to the guide and there we are not providing any explanation of what we attempted in the migration and we are not providing any option of fixing the data, only a script to delete tracked entitities and with all the enrollments and events.

To resume:
If the user has a number x of "fixable" tracked entities and one that is not automatically fixable, we are deleting ALL the tracked entities with inconsistent data.

[ameenhere]

Before we merge this, can we make sure we update the dev db snapshot to have this "fixing scripts" run? So that we don't break dev again for Phil to fix later.

[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

[enricocolasante]

For this kind of process that deal with data we need to be much more clear with the user and very very careful on any step.
Here you are fixing inconsistent data in a correct way, getting the tracked entity type from any underling enrollment but this is not the only issue that could happen and this SQL is running in a transaction (even without specifically start the transaction as done here, flyway will wrap this in a transaction), so if there is any inconsistent data that cannot be fixed in the way you provided, no data is fixed.
Than the user is sent to the guide and there we are not providing any explanation of what we attempted in the migration and we are not providing any option of fixing the data, only a script to delete tracked entitities and with all the enrollments and events.

To resume:
If the user has a number x of "fixable" tracked entities and one that is not automatically fixable, we are deleting ALL the tracked entities with inconsistent data.

[ameenhere]

I did not understand why do we have two ALTER COLUMN SET NOT NULL on the same table-column combination?

[zubaira]

If the initial migration fails due to invalid data, it will raise an exception, prompting the user to correct or remove the problematic data. Once the issues are resolved, the same migration can be reapplied, and the ELSE condition will enforce the NOT NULL constraint on the column.

[ameenhere]

Then, can we move the ALTER TABLE to outside the IF ELSE condition, since it is executed at the end anyway?