I think it's not currently possible in envers to trigger a change indirectly to a parent entity.
I don't know if it's easy to do...
In your example, suppose there is another entity, let's say park, that has a collection of residents too. Envers doesn't know all entities that have a relation with another. You need to tell envers which relations you want to trigger a indirectly change and which not... or you could trigger a lot of indirect changes in a tx.
I hope you understand my idea. And maybe someone else can help you.
Thanks, Hernán. I am wondering if Envers provides a mechanism to establish that type of relationship, i.e. when this entity changes, this related entity should also change. It seems like it does not.
In fact the correct solution here would be to be able to get the revisions at which an entity and some related entities changed, e.g. I want to get changes of Parent entity and all Child entities related via the children field.
Implementing this shouldn't be very hard using the new ValidTimeAuditStrategy.
Using the "house: residents" example, I can see that I'd be able to iterate through all the residents and, based on when they've changed, implicitly understand that the house has changed. However, that could be very time consuming, especially if we get into another level, i.e. changes to a collection associated with a resident. We may have to examine thousands of records - and consequently make a lot of database calls - to see that the house has changed.
Or I'm not understanding what you're saying, Adam...
Well, it all depends on what you consider a change to the house. Is a change of the resident's name a change of the house? (btw. currently, a new rev will be generated if the collection of residents changes - that is if an element is added or removed).
That's why you would need a new mechanism to find all revisions of an entity plus of associated paths using one query. E.g.:
auditReader.findRevisions(houseId, House.class, "house.residents")
would mean that you want all changes to a given house plus all changes to the residents. That would issue one DB query to find the appropriate revisions.
If I'm not missing something vital, I think this should be possible to implement using the new validity audit strategy.
I noticed the collection member changes are creating new revisions of the owning entity, which is pretty awesome.
The type of query you discuss would be very helpful. I'm just starting to look at the source code of Envers, but in the meantime, if you wanted to expand the API to include that, I wouldn't be offended .
As for the collection member changes being regarded a change, there's a config option - defaults to true. Note however that if you don't change the collection by adding/removing elements, a rev won't be generated.
I'd love to expand the API, but I'm pretty much swamped by "normal" (aka paying) work