Uploaded image for project: 'OpenMRS Core'
  1. OpenMRS Core
  2. TRUNK-3174

Add annotation to suspend recursive handling in RequiredDataHandler

    XMLWordPrintable

    Details

    • Complexity:
      Undetermined

      Description

      In RequiredDataAdvice, all RequiredDataHandlers are called on all child collections the OpenmrsObject being handled.

      Therefore, for instance, if you void an Encounter, the VoidHandler is called for all Obs associated with that Encounter. In a one-to-many relationship, this is the functionality we want, but it is not necessarily what we want in a many-to-many case. For instance, in a module I am writing I have created a "ProviderRole" object that contains the collection of RelationshipTypes that the particular ProviderRole can support. As more than one ProviderRole can support the same relationship type, when retiring a ProviderRole we do NOT want to retire the associated RelationshipTypes. This is what now happens.

      I propose we create a new annotation, @NoRecursion (I'm definitely open to the suggestion of better names!), that can be applied to a Collection of an OpenMRS object. This annotation would have a mandatory attribute "handler" which would the be the name of the handler type to NOT apply recursively. For instance, in my case I'd have something like this:

      public class ProviderRole extends BaseOpenmrsMetadata implements Serializable {
      
          private static final long serialVersionUID = 1L;
      
          private Integer providerRoleId;
      
          // the provider/patient relationships this role can support
          @NoRecursion(handler = RequiredDataHandler.class)   // if we wanted to ignore just the RetireHandler, we'd do @NoRecursion(handler = RetireHandler.class)
          private Set<Relationship> relationshipTypes;
      

      Thoughts?

      I'd need to be able to backport this to 1.9.x (though it is fine if it doesn't get in until the 1.9.1 release).

        Attachments

          Activity

            People

            Assignee:
            mogoodrich Mark Goodrich
            Reporter:
            mogoodrich Mark Goodrich
            Votes:
            2 Vote for this issue
            Watchers:
            5 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: