Indirect versioning of parent entities

[anotherchrisberry]

Hello,

I am wondering if it's possible to set up Envers in a way that it will create a version of a parent entity when a child entity changes - even if that change to the child does not trigger a change to the parent directly. For example, you have a house object and the house object has a set of residents. If you add or remove a resident to a house, Envers will create a new revision of the house, even though you don't explicitly change the house object.

However, if you change the name of a resident object, the house object is not going to be considered changed and thus not revised. But is there some mechanism to force the house object to be treated as a new revision? One way I can imagine doing this is to have an arbitrary, meaningless field on the house object, which the resident object would update, then saving the house object as well as the resident. But this seems like a messy hack in order to track the state of an object as associated objects change.

Thanks, and I apologize if this has been asked before.

Chris

[hernanbolido]

Hi!

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.

Regards. Hernán.

[anotherchrisberry]

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.

[adamw]

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.

Adam

[anotherchrisberry]

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...

[adamw]

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.

Adam

[anotherchrisberry]

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 .

Chris

[adamw]

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

Adam