Uploaded image for project: 'Sync Module'
  1. Sync Module
  2. SYNC-357

Sync does not correctly replicate null values to remote server

    XMLWordPrintable

Details

    • Bug
    • Status: Closed
    • TBD
    • Resolution: Fixed
    • None
    • 3.0.0
    • 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

      Gliffy Diagrams

        Attachments

          Activity

            People

              mseaton Mike Seaton
              mseaton Mike Seaton
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: