Have you implemented OpenMRS? Please participate in the Implementation Site Survey. If you already have, thank you!
Child pages
  • Sync object hash code detection
Skip to end of metadata
Go to start of metadata

Purpose

Every object synchronized using the Sync module is being compared with the current database state in order to avoid overriding important data. This mechanism allows detecting conflicts during synchronization and is implemented as objects' hash codes comparison.

Hash code generation

Hash codes are generated using the SHA2-512 algorithm which produces 128-characters long output. Every object is parsed to its JSON representation and provided as an input of that algorithm.

In order to produce a hash code you have to give the object converted to SimpleObject class and its original class. If you need to converts an object to SimpleObjects you can use UnifyService.

SyncHashcodeUtils:

getHashcode
String getHashcode(SimpleObject simpleObject, Class<?> clazz);

Fields skipped by hash code method

Object's fields, which the hash code method omits, are listed below:

  • BaseOpenmrsData:
    • voided
    • dateVoided
    • voidedBy
    • voidReason
  • BaseOpenmrsMetadata
    • retired
    • dateRetired
    • retiredBy
    • retireReason
  • AuditInfo
    • creator
    • dateCreated
    • changedBy
    • dateChanged
  • Links
    • REST HATEOAS 

Please consider this situation. An child instance receives a parent's object, which was previously pulled and voided later on the child. Now, when we have pulled parent's object again we want to link that object to child's voided version of it in order to avoid saving old version of the object. To do so, hash codes have to be identical for these object (parent's non-voided & child's voided). That is why voided and retired related fields are skipped. 

  • No labels