(More comments, which I wrote over several days, so are probably chaotic)
"Metadata resource list" comments:
- The word metadata is used incorrectly throughout these wiki pages, to mean "stuff that can't be represented in FHIR". A lot of our metadata can't be represented in FHIR, so there's overlap, but really the distinction is things that CAN vs CANNOT be suitably represented using FHIR.
- Order is important clinical data that really needs to be using FHIR (e.g. DrugOrder => MedicationRequest)
- GlobalProperty needs some mechanism to decide whether to sync things at the row level (i.e. some of these are system settings that you wouldn't want to sync; I'm not sure if there are any GPs that you do want to sync)
- I would sequence the work so that metadata sync happens later on. E.g. if an implementation can get all their metadata to be consistent through some other deployment process, they can adopt sync early, even without this function.
"Sync 2.0 Architecture Overview" comments:
"Sync 2.0 configuration variables" comments:
- I would default the "enabled" variables to false (since things won't actually work without some configuration)
- Is the idea that changes would be captured and written to the atom feed always, regardless of whether push and/or pull are enabled? We might also want a setting like
sync.enabled that controls this.
About error handling: are we going to preserve the downloaded REST/FHIR response to replay again? Or would we re-fetch it from its url?
The event module uses ActiveMQ, which has been occasionally buggy for us. (Maybe we're just using a 5 year old version of it.) We should definitely consider either modernizing the event module, or writing a from-scratch replacement, that can be used for Sync 2.0 and other things too. But for Sync 2.0 the real requirements is to have something that goes from hibernate interceptor events to atom feed events. We could go via a message broker like in the event module, which could be more reusable, but also adds (unnecessary?) complexity.
Good point. So, yes, it's fair to prioritize logging. I wouldn't over-complicate by giving too much configuration about which loggers to use. Just pick a good default, at least in the first pass.
I was also thinking about this. Personally I would prioritize "quicker to develop" above "conflict resolution". (Ultimately, it would be nice to capture a complete change history in openmrs-core, or in a multi-purpose module, not just for sync.)
Even to do something simple like comparing based on dateCreated/dateChanged requires that we persist an extra piece of data on each update (i.e. what was its original created/changed timestamp) so we can do a 3-way comparison when merging. If this can be done while generating the atom feed, without adding lots of complexity, it could be worthwhile.
I wonder if we can leave a hook to add conflict resolution in at a later date, once a separate module has been built that captures a full change log.