Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
wants to merge 30 commits into
base: master
Choose a base branch
from

Conversation

zubaira
Copy link
Contributor

@zubaira zubaira commented Nov 9, 2024

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.

@zubaira zubaira marked this pull request as ready for review November 19, 2024 08:35
@zubaira zubaira requested a review from a team as a code owner November 19, 2024 08:35
@zubaira zubaira changed the title feat: Add not-null constraint for column trackedentitytypeid in trackedentity table [DHIS2-15066] feat: [WIP] Add not-null constraint for column trackedentitytypeid in trackedentity table [DHIS2-15066] Nov 20, 2024
@zubaira zubaira changed the title feat: [WIP] Add not-null constraint for column trackedentitytypeid in trackedentity table [DHIS2-15066] feat: Add not-null constraint for column trackedentitytypeid in trackedentity table [DHIS2-15066] Nov 21, 2024
Copy link
Contributor

@enricocolasante enricocolasante left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment on lines 163 to 164
femaleA.setTrackedEntityType(trackedEntityType);
femaleB.setTrackedEntityType(trackedEntityType);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

setTrackedEntityType

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed

WHERE trackedentitytypeid IS NULL
)
LOOP
UPDATE trackedentity
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Contributor

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.

Copy link

sonarcloud bot commented Dec 6, 2024

WHERE trackedentitytypeid IS NULL
)
LOOP
UPDATE trackedentity
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

ALTER TABLE IF EXISTS trackedentity ALTER COLUMN trackedentitytypeid SET NOT NULL;
ELSE
RAISE NOTICE 'No inconsistencies found, trackedentitytypeid is already populated.';
ALTER TABLE IF EXISTS trackedentity ALTER COLUMN trackedentitytypeid SET NOT NULL;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants