Hi. At PIH, we have a few implementations using both sync and namephonetics. Right now, namephonetics objects aren't propagating through sync which is something we want to fix.
Option 1 is to have NamePhonetics extend OpenmrsObject, and let sync propogate these. The downsides are 1) extra stuff in the payloads, and 2) I have a feeling there would need to be explicit handling of NamePhonetics objects during ingest, because PersonName objects are explicitly marked as getting processed last (because of the famous TreeSet re-ordering bug). This, i think, would mean that there would have to be a new category of 'things to process last' in the ingest routine, which in sync we could maybe define safely as anything associated with a module (org.openmrs.module*)? Not sure about this though. It is definitely true that we don't want to build any module dependencies between Sync and NamePhonetics. Option 2 is to treat NamePhonetics like ConceptWords in that they're calculated locally. NamePhonetics currently AOPs around savePerson to do this on a local system, but the saving of PersonNames during sync ingest uses the SyncService.saveOrUpdate method. Here's what I was thinking -- what if SyncService had a postInterceptor modeled on RequiredDataAdvice? This postInterceptor class would check for registered handlers for incoming sync items. The only architectural piece that would be needed to do this and avoid building in module dependencies between Sync and NamePhonetics would be a truly default Handler interface in OpenMRS core. NamePhonetics would then register a PersonName handler. Sync ingest would then look for a handler in the saveOrUpdate postProcessor, and if found, apply it. If not found (for sync implementations not using namephonetics), no problem. Option 2 seems like overkill, maybe, although i like the idea of keeping sync packages as simple and small as possible... thoughts on this would be appreciated. Also, generally, would it be useful to have a truly generic handler interface in core (or actually, maybe generic pre-processor and post-processor handler interfaces)? This would be kind of a cool way for modules to register handlers against each other, without building in module dependencies. d _________________________________________ To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [email protected] with "SIGNOFF openmrs-devel-l" in the body (not the subject) of your e-mail. [mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l]
