In Bahmni, in patient registration to load an existing patient we use PatientResource* from openmrs-module-webservices.rest. Here PatientResource1_8 we have a property getter for “person” where we are creating a new person object based on the patient instance. With upgrade to openmrs 2.1.x there is a change in Person constructor to do a deep copy of collections in person => we will get new objects in all those collections. Hence the final Patient object has patient names with different uuids than the original one. When we change the patient name from Bahmni UI, since the uuid is different, every time we save there is a new record in patient_name table. This happens irrespective of whether we change the patient name or not.
One possible fix could be to copy the uuids as well when we do a deep copy of person names the way we are doing for person object in the same constructor. Another possible way could be to modify PatientResource in the @PropertyGetter for “person” instead of creating a new instance from patient object, load the person object using person service. Is this right approach?
Can you please suggest if there is a better way to do this?
I’d think there is other areas in the code base that depend on that constructor that would be affected negatively if it copied over uuids, the option of loading the person object from the DB seems viable to me.
The thing is that the Patient extends Person, so in theory we should just be able to change the patient resource to return the patient itself (instead of new Person(patient)). It looks like we used to do this before changing it to fix a bug.
We should also check whether that one-line change would fix things, or if it was truly necessary for that bugfix.
Wyclif, what’s the intended usage of the new Person(Person) constructor?
We looked at this on the design call today, and we realized that the deep copy introduced recently was not serving any useful purpose, so I am reverting the changes that were in TRUNK-4925.