Details
-
Bug
-
Status: Closed
-
TBD
-
Resolution: Fixed
-
None
-
None
Description
In working on SYNC-356, we did a little refactoring of the SyncUtil and SyncIngestServiceImpl classes, and during the course of that refactoring, came across some code that appeared to only set values on Ingest if they were non-null.
Probing deeper, this does seem to be the case. cioan put together a nice little unit test that demonstrates this problem, which has been committed to a new branch ( draft PR here: https://github.com/openmrs/openmrs-module-sync/pull/48 ) which should be used to develop a fix for this issue.
The issue is that:
a) On the source server, the HibernateSyncInterceptor only seems to include non-null properties in the sync record payload. See HibernateSyncInterceptor#
packageObject, where there is a loop that iterates over an object's properties (hibernate class metadata) and only adds the property to the sync record if the current state is not null.
b) On the target server, the SyncIngestServiceImpl / SyncUtil classes only set new property values on the target OpenMRS Object if the property values are non-null.
This results in tests like cioan put together to fail:
1. On a child server, a person's birthdate is changed from a non-null value to a null value (any nullable property can be used to demonstrate this, this was chosen for convenience) and this is saved.
2. On the parent server, after sync is completed, the person's birthdate remains at it's existing non-null value. The newly changed "null" value is not set. Thus, the child and parent are now in inconsistent states.
mogoodrich FYI