2 Replies Latest reply on Jun 28, 2013 5:44 AM by Piotr Findeisen

    @ModifiedEntityNames with entity names rather than class names

    Piotr Findeisen Newbie



      I'm in the process of adding Envers to a... hm.. a bit complex project. I noticed that by default @ModifiedEntityNames stores fully qualified class names of entities.

      However, this can impact my abilit to refactor / restructure the code -- the class names are now fixed as they are stored in the database.


      Would it be possible to store entity names (i.e. the value of @Entity.name, defaulting to simple class name) instead?

      I don't expect any change in Envers happening overnight, but I would appreciate a guidance whether this is possible and how to achieve this.


      So far I came up with the following plan:

      1. Implement my own EntityTrackingRevisionListener
      2. In entityChanged()store entity name (not the entityName parameter, this being the FQN of the class) in some property, say realEntityNames
      3. Create a 'fake' @ModifiedEntityNames @Transient proeprty that simply retrieves values from realEntityNames converting them back to FQNs (without that CrossTypeRevisionChangesReader won't work)
      4. Somehow cheat the DefaultTrackingModifiedEntitiesRevisionInfoGenerator (used automatically if only I have @ModifiedEntityNamesin my entity -- so essentially always if i want to have CrossTypeRevisionChangesReader) that my fake property is ... good one. Returning immutable set will not necessarily allow transaction to complete.


      Will this work? -- Not only in those some cases I can imagine and test now.

      Can I do better?

      Can envers allow to supply my own implementation of ModifiedEntityNamesReader? This would make me more safe... and I would not need 'fake' properties.



      Piotr Findeisen

        • 1. Re: @ModifiedEntityNames with entity names rather than class names
          Adam Warski Master

          Sure it could allow you to use your own implementation of ModifiedEntityNamesReader - just change the code & create a pull request That would be the easiest option I guess.


          Not sure how the cheat could work, though



          • 2. Re: @ModifiedEntityNames with entity names rather than class names
            Piotr Findeisen Newbie

            Hi Adam,


            Thanks for your explanation.

            My cheat -- yeah, I got this working, but this is already a third cheat in a row against envers code and I would still prefer to remove it and use some official API as soon as it's available.


            I see the following open options

            1. Direct support for the feature I want at this point:
              • '@ModifiedEntityNames' could have attribute selecting what is stored -- entity simple name or class FQN
            2. Have 'ModifiedEntityNamesReader' as an interface, allow users to provide own implementation (either via a proeprty configuration or via an attribute on '@ModifiedEntityNames', allowing this annotation to be put on the revision entity class)
            3. Do not directly address the problem, however if @ModifiedEntityNames is also @Transient still use DefaultRevisionInfoGenerator instead of DefaultTrackingModifiedEntitiesRevisionInfoGenerator


            First option is most user-friendly, as it is a matter of choosing different attribute value for an already existing annotation to have the functionality that i want today.


            However, second option seems more flexible. For example, if i wanted to enhance 'REVCHANGES' table with some additional info (like count) I would need to map it to an entity collection rather than @ElementCollection. First option would not give me that, second and third would.


            Third option - I think that might not constitue an ideal API though. Not really intuitive but will 'just work' in my case.