2007-07-27 Sync Conference Call

Attendees: Julie, Anders, Darius, Maros

Discussion Summary:

  • Lesotho needs *something* NOW, without lite-lite (i.e. one way 'dump') openmrs is unusable for them. Given that, meeting their basic needs is our short-term driving factor. While we can meet their need with simple dump and transport: it really isn't even sync, we all believe that accomplishing the same (i.e. a one-way sync of data from child to parent without any need for conflict resolution) can be implemented on top of sync mechanism with incrementally 'insignificant' amount of work: thus we would prefer to not do a 'dump and transfer' and instead focus on getting simple sync out.
  • The facilities minimally needed to implement sync so that it can be used to meet Lesotho needs:
    • Serialization + Change detection
    • Sync packaging and transport
  • Serialization + 'Change detection'. We have a lot of ideas, what we are lacking is a summary of pros/cons of the different approaches and then the decision. The three approaches to serialization:

a) XStream, b) Simple, c) Custom code (ala Julie and/or openMRSSerializable).

    • if we take 3rd party code: what is the benefit vs. liability? Potential benefits: less code, automatic object graph traversal and dealing with circ. references
    • observation: having to write converters is not going to result in significantly 'less code'
    • observation: Both XStream and Simple will not work out of box: for XStream we will need converters for nearly each class, for Simple we would have to take a branch of their code and maintain it with little 'unique' benefit
    • observation: we *can* change our mind later and evolve/replace the solution if needed; it doesn't have to be perfect from start and meet every possible use case
    • conclusion: let us start with custom serialization code and see if it can meet our immediate needs
    • serialization of object graphs - how do we do this with custom code? Idea: why not leverage hibernate's interceptors that during flush traverse object hierarchies already. It seems that for our purposes the following approach should work:
      • each object serializes it's primitive or object properties; *collections* are NOT serialized -- this is how Hibernate works by default
      • Let Hibernate traverse the contained collections (using its' mapping file) and we will detect changes to them in Hibernate interceptor. What this means is that Patient would serialize its patient_id, creator, date_created, but *not* identifiers or addresses: how this would work is easily seems from looking at the hibernate mapping files: 'property' gets serialized; 'set' would not.
  • Sync packaging and transport
    • Let's use the notion of SyncRecord as a container or SyncItem which holds the serialized object state
    • SyncRecords are then held in local journal (a queue). In case of implementation using hibernate interceptor, SyncRecords are continuously put into the journal. Maros checked in a starting point for SyncRecord: checkout the implementation and specifically SyncRecordState enum
    • The 'export' of clients changes is then simple a file containing List<SyncRecord> serialized in XML.
    • we assume GUIDs are in place -- maros to create sql update script

Take-aways:

    • Julie to prototype the custom serialization and interceptor implementation. Also, see if this can be used to generate the 'dump' of the database if we were to 'touch' all local records.
    • Maros/Anders: drive the implementation of SyncRecord, SyncJournal (or SyncQueue)
      • based on Maros/Anders discussion later on, Anders will focus on the getting the following done in next week:
      • implement the queue/journal (what do we want to call this? SyncJournal?) in terms of a collection of SyncRecords, implement SyncJournalManager to allow basic operations (i.e. allow interceptor to add new syncrecords, update status, generate exportfile, etc..)
      • Implement simple export of the journal: Create admin section for Sync, add 'export local changes' button to get it to spit out xml change file. For now, fill in syncItem.content with made up with dummy hard-coded data -- this will be replaced by Julie's implementation..
      • Guids: maros to make a sql script update and corresponding class changes
Retrieved from "http://openmrs.org/wiki/2007-07-27_Sync_Conference_Call"