memodel cannot be deleted unless the MEModelCalibrationResult is first deleted

[dkeller9]

Description

A memodel cannot be deleted directly if it has a MEModelCalibrationResult. However, the MEModelCalibrationResult is meaningless without the memodel.

Acceptance criteria

• Discuss the issue
• If it is determined that MEModelCalibrationResult should be automatically deleted during deletion of the parent memodel then do so

[eleftherioszisis]

Given that the memodel is referenced as an input by these entities, and those entities are part of an activity task's provenance graph, it makes sense not to allow its deletion. Otherwise, deleting an memodel for an unrelated reason could unexpectedly mutate the provenance of an existing task activity, resulting in changes that occur out of context.

On a related note, we should discuss whether it would be beneficial to expose the foreign key information to users. Doing so would make it clear which resource must be deleted or updated before the target entity can be deleted, making the dependency explicit and the deletion workflow easier to understand.

[dkeller9]

If an MEModelCalibrationResult is solely derived from an ME Model, which other activity tasks would use it? In my opnion, the most consistent policy would be for the downstream artifacts of deleted entities be to deleted along with the parent. Most users would regard it as a bug if they cannot delete an memodel that they just created. The deletion steps themselves should also be part of provenance, so it should always be clear what was done.

Perhaps the point we can agree on is that the conflicting foreign key information should be exposed, so that the user can easily remove the blocking entity.

[dkeller9]

One idea might be to have a flag in entitycore that would allow deletion of downstream entities, with the default being set to False.

[eleftherioszisis]

If an MEModelCalibrationResult is solely derived from an ME Model, which other activity tasks would use it? In my opnion, the most consistent policy would be for the downstream artifacts of deleted entities be to deleted along with the parent. Most users would regard it as a bug if they cannot delete an memodel that they just created. The deletion steps themselves should also be part of provenance, so it should always be clear what was done.

Perhaps the point we can agree on is that the conflicting foreign key information should be exposed, so that the user can easily remove the blocking entity.

I think it makes sense to add the deletion cascade in that case. @GianlucaFicarelli thoughts?

One idea might be to have a flag in entitycore that would allow deletion of downstream entities, with the default being set to False.

That would be quite hard to do because deletion cascades are part of the database migration.

[GianlucaFicarelli]

Although the ticket has been opened for MEModelCalibrationResult, we should consider also ValidationResult that is defined quite similarly and has the same issue.

In both the cases, the Result is an entity that is strictly linked to the main entity.

In general there isn't a restriction that forbids any user in any project to register a private or public Result for a public entity, and automatically deleting an entity on cascade in a different project would be unexpected and probably wrong.

Moreover, this would be the first case of entity deleted on cascade by another entity. For reference:

• Capability (P2): Deletion cascades for entities #361
• https://openbraininstitute-my.sharepoint.com/:w:/g/personal/eleftherios_zisis_openbraininstitute_org/IQAr67NEgkx4TLMkFKRq9_c6AckgvaKaabb4ZQJW66nL-Sw?e=3L7h8E&wdExp=TEAMS-TREATMENT&web=1&TeamsCID=1faa8625-0eb7-4e60-8bd1-5afeb763fa15&linkOpenTime=1783070600003

However, if we restrict the creation of the Results to be in the same project, it seems acceptable to apply a deletion on cascade.
In the production db at the moment all the Results have the same authorized_public and authorized_project_id of the entity that they refer to.