-
15. Re: entityNames in envers
Hi Adam,
The extra case is when the user has a reference that belongs to an object relation marked as NOT_AUDITED. The First message in this post explains the case... The other option is to give the user a way to know if an entity is a NOT_AUDITED one and let the user use envers or core for retrieving the instance, but I followed the other option because we agreed that on this post... maybe I get the wrong idea?
-
16. Re: entityNames in envers
Yes, sorry, I know we agreed but I was having second thoughts .
So there already is a method for checking if an entity is not audited - by using the isEntityClassAudited. My new worry came from the fact the the findAll method would have the revision argument, which doesn't have any sense if the entity is not audited.
In your use-case, would checking if an entity is audited be much harder than calling findAll?
Adam
-
17. Re: entityNames in envers
Hi Adam!
Firt of all, in my use-case I could check all and decide to ask envers or core. Also I think that cheking if an entity is audited is not enough.
We should provide a way to asking for the NOT_AUDITED relations. If not, this kind of relations and the @NotAudited could be mixed by the users and retrieve an actual instance in a relation that envers doesn't audit.
Besides that, the point that is good for me using the findAll() method is that the user does't know when a relation is audited or marked as NOT_AUDITED. Probably (that's my case) the revision number from the root object would be the revision number for the whole graph. So the user uses that revision number for all relations and doesn´t realize about envers internal structure (we don't give information about revisions in the related instances returned by envers, so the user doesn´t know the real revision for them, and that's really nice )
Thanks for your answers. Tell me what do you think about it. Of course I can change the patch to take out findAll method, but I wanted to tell you my point of view.
Regards. Hernán.
-
18. Re: entityNames in envers
But if you want to check a relation, then you must have the relation info. If you do, then you know the target entity. You can check if the target entity is audited or not. Then you know if the realtion is audited or not, right?
Adam
-
19. Re: entityNames in envers
I'm thinking that we have 3 possibilities for relations:
- @Audited
- @Audited(targetAuditMode=NOT_AUDITED)
- @NotAudited
User can check for situation 1. In order to determine if the relation 2 or 3 envers should provide a way to check option 2.
I hope I explained my idea clearly, it's difficult explaining ideas through the posts.
Regards. Hernán.
-
20. Re: entityNames in envers
Ah of course, sorry for being so dumb (esp for code that I've written myself).
Then we would need a method to check for a relation, true.
Would it be much work for you to change the patch to include the method to check the type of relation? I think a findAll method with the sometimes-ignored rev parameter may be confusing. Very sorry about the changes
Adam
-
21. Re: entityNames in envers
Adam,
Of course I can do that! I will work on it and come back with the new changes. I'll remove findAll() methods then.
Regards. Hernán.
-
-
23. Re: entityNames in envers
Glad you've been able to work things out! I've been really busy the last few weeks so I didn't have time to jump in.
Hopefully things should improve after next week. Looking forward to a complete patch ;-)
Kind regards, Erik-Berndt
-
24. Re: entityNames in envers
Hi!
Well... after all this time I managed to create the pull request. I've been quite busy and I have to deal with gradle too, which was new for me.
Sorry for the delay.
I hope it will help.
Regards. Hernán.
-
25. Re: entityNames in envers
Hi,
Apart from a week's holiday, I've had a very busy time too. I hope to take a good look sometime this week, but unfortunately I can't promise anything currently.
Kind regards,
Erik-Berndt