1 2 Previous Next 25 Replies Latest reply on Nov 15, 2010 2:14 PM by Erik-Berndt Scheper

    entityNames in envers

    Hernán Chanfreau Master



      We realized that for fully supporting entityNames in envers, it would be necessary to incorporate some issues, besides modifications already done.

      These issues are useful for envers users, who are using the dto pattern for carrying information to a front end application.

      In order to avoid carrying the whole historic model to the front end application, DTOs contains “references” to objects instead of real objects (i.e. a lazyness solution at DTO level). However, in this scenario, it is necessary to know the entityName of each “lazy” object for building those references.


      I was thinking about the tasks we should carry out to achieve a solution (I´ve already done some of these changes):


      • Giving support to obtain the entityName for an object inside the graph (for root object is trivial)
        • Add a new cache for id, rev,object -> entityName in FistLevelCache.
        • Open AuditReader API for getting entityName for a given envers object (i.e. an object previously retrieved by envers). This feature is supported in CORE through Session API.
        • Add the method >>isEntityNameAudited() to the class AuditReader.


      • Giving support to obtain the NOT_AUDITED relationships. I see two different solutions (and prefer the second one):
        1. There      should be a way to ask Envers if an object reference is a NOT_AUDITED one.      Then, ENVERS users will use it to get this associated objects via CORE.
        2. The      method AuditReader>>find() look up the associated instance via core      for every relationship configured as NOT_AUDITED. Do the same for the      getEntityName() method. In this solution, ENVERS users doesn’t care about      this type of relationahips.



      What do you think about this?


      Regards. Hernán.

        1 2 Previous Next