Allow updates to Data Elements to change the parent Data Class

[pjmonks]

Description

There is a requirement to be able to move a Data Element to a different Data Class within the same Data Model. At the moment, the PUT /api/dataModels/{modelId}/dataClasses/{classId}/dataElements/{elementId} will fail if a different dataClass parent UUID is included in the request body.

Steps to reproduce

Send this request:

PUT /api/dataModels/{modelId}/dataClasses/{classId}/dataElements/{elementId}

{
    "dataClass": "{anotherClassId}"
}

Note that the model property is not included in the body - this should still not be allowed, since moving a data element outside the model to a different model would cause links to the data type to break.

This is the exception currently thrown:

deleted object would be re-saved by cascade (remove deleted object from associations): [uk.ac.ox.softeng.maurodatamapper.core.facet.BreadcrumbTree#c665b724-fed0-4918-8197-d78286034371]

Expected behavior

A 200 OK should return in the response. Once complete, the data element should now appear in Mauro under it's new data class parent.

Related

• NHSDigital/DataDictionaryPublication#468

[pjmonks]

Adding a new endpoint to adjust an existing DataElement and change the parent data class is being problematic. The issue is the breadcrumb tree won't update as expected, since it won't persist changes back to the database without causing constraint violations.

Going to put this on hold and see if I can just use the MDM UI and existing endpoints to copy a data element to the target data class, then delete the old one.

[pjmonks]

Change of plan. Instead, I will attempt to keep the move endpoint but that will internally handle a copy of the original data element and delete the original. This will then simulate the "move" of the element to a different class.

Keeping the move endpoint will be necessary so that the NHS Data Dictionary will be able to track and intercept changes in paths by tracking the action name.

[pjmonks]

Now going to put this on hold. Technically this work is not in the statement of work agreed with NHS England and building this feature is taking up time - there may not even be a need for it depending on discussions of re-organising the dictionary structure in Mauro.

Parking for now, we may revisit the work and complete later.