@craigappl: I am afraid your changes will probably throw liquibase error on databases on which it has already run. Can you fix it with the “validCheckSum” for the changeset?
regarding the default entry in ‘chunking_history’ table, I have done that already on master.
@maimoonak: if you are going to be publishing the library under “org.opensrp” groupid in a mvn repo, then you can do that with your current fork. If you rather have the code, at a single place and merged and maintained by ict4h, then I suggest the following approach:
- add the additional advice over core EncounterService
- add to the config.xml. now we will have advices over both the encounter serivces (core & emrapi)
- as long as the categories for the event in the 2 encounter advices are different (currently it is not), then it will be fine. other than additional records in the event table!
- alternatively, if you want only one event raised for encounter, then use a global property like “atomfeedEncounterInterceptClass”, which you can check in the “afterReturning” intercept method and selectively raise event.
- or if you think EmrEncounterService advice suites your requirements and you only need to override the event content path to point to core encounter rest resource, then use a global property to externalize the “ENCOUNTER_REST_URL”, keeping the default as it is.
- another option would be, write both the advices, but don’t configure advices in “config.xml”. Use the ModuleActivator.started() method to wire up the encounter advice based on a global property.
Note, all the above, will still not make the module generic. Only patient and encounter events will be raised.