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

Update dateChanged and changedBy fields on Auditable objects through a hibernate interceptor



    • Complexity:


      Currently, when an OpenmrsObject is saved, a number of SaveHandlers automatically kick in and modify it. These serve to ensure fields like "creator", "changedBy", etc. are completed consistently. In doing this, the SaveHandlers check every property of the object being saved, and if the property is a Collection<OpenmrsObject> then it recursively performs it's action on all of the children within the Collection.

      In some cases, this may be the behavior that we want (for example, if a new Person is created with a new PersonName and a new PersonAttribute, and we save that Person, we would like the creator and dateCreated properties of all of these objects to be saved with the same User and Date automatically).

      In other cases, however, this is not the behavior that we want. For example, if you modify a Person's gender and then save the Person, you do not want the changedBy and changeDate properties to be updated on that Persons names, addresses, and attributes.

      In the case of the reporting framework, this has appeared as a bug as raised by Ada in this thread:

      In the reporting framework, it is common to have a Definition object (eg. a CohortDefinition), which contains a List of OpenmrsObjects. Saving such Definitions should never implicitly or explicitly perform any modification on the underlying Objects that they reference. However, this is happening as a result of the action of the SaveHandlers. She is running the reporting module on a database where the Concept table is read-only, and is trying to save a CohortDefinition that references a List of Concepts. This is failing due to the fact that the system is attempting to modify and save the Concepts due to their interaction with the SaveHandlers when the CohortDefinition is being saved.

      We need a solution to this problem that allows for this behavior to be turned on and off as needed depending on the object relationships involved. Annotations would be a likely candidate for a solution. By default, it would be useful if recursion was turned off, and annotations could turn it on, as this would allow the reporting module to "just work".

        Gliffy Diagrams


            Issue Links



                mogoodrich Mark Goodrich
                mseaton Mike Seaton
                0 Vote for this issue
                9 Start watching this issue