@ModifiedEntityNames with entity names rather than class names

[findepi]

Hi,

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.

Best,

Piotr Findeisen

[adamw]

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

Adam

[findepi]

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.