-
1. Re: @ModifiedEntityNames with entity names rather than class names
adamw Jun 27, 2013 12:07 PM (in response to findepi)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
-
2. Re: @ModifiedEntityNames with entity names rather than class names
findepi Jun 28, 2013 5:44 AM (in response to adamw)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
- Direct support for the feature I want at this point:
- '@ModifiedEntityNames' could have attribute selecting what is stored -- entity simple name or class FQN
- 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)
- 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.
- Direct support for the feature I want at this point: