Tarek - There are a few ways we can tackle what you want all within the scope of Envers, but some of it highly depends upon details specific to the relationship between Product (P) and Offer (O). 1. What is the collection type used in Product for the related offers? If this happens to be a List<>, would it be possible to use a Set<> instead? 2. Is there a requirement that Offer should own the relationship with Product? In other words, is it possible to invert the relationship such that the collection side is the owner instead? Chris On 09/01/2016 06:14 AM, Dev Stack wrote:

Tarek - See inline. On 09/01/2016 10:11 AM, Dev Stack wrote: What I meant here was more along the lines of keeping the bidirectional relation, but instead of the @ManyToOne being the owner of the mapping, we'd invert it so that the @OneToMany owned the relationship. The mapping would then be: @Entity @Audited public class Product { ... @OneToMany @JoinColumn(name = "product_offer") @AuditMappedBy(mappedBy = "product") private Set<Offer> offers; ... } @Entity @Audited public class Offer { ... @ManyToOne @JoinColumn(name = "product_offer", insertable = false, updatable = false) private Product product; ... } We want to do this to take advantage of Envers' REVISION_ON_COLLECTION_CHANGE. See below in your point 2 as to why. You get this by default. Regardless of which side owns the relationship, any change made specifically to a Product that does not change the associated Offer instances, only a revision is triggered for Product, allowing Offer instances to point to the older versions of a Product when they're queried. If we assume a Product and Offer were created in revision 1 and subsequently the Product was modified in revision 2, the following are true: auditReader.getRevisions( Offer.class, offerId ) = [1] auditReader.getRevisions( Product.class, productId) = [1, 2] So querying Offer at revision 1 would give you the product instance at revision 1 Offer offer = auditReader.find( Offer.class, offerId, 1 ); offer.getProduct() = Product at revision 1 I think it makes more sense to enforce this through Envers than polluting the domain model, but that's just my opinion ;). The cleanest way is to invert the relationship as I described above and change the collection type to a Set<>. The setting REVISION_ON_COLLECTION_CHANGE will take affect since Product now owns the relationship and any change you make to an Offer, the owning entity (Product) will be revised automatically. In other words, changes to an Offer will force Product to update and so the revision number query logic from 1) holds true and helps us here too. NOTE: Just be sure you implement the appropriate equals/hashCode logic for Offer so that changes are properly detected. If you decide you don't want to use REVISION_ON_COLLECTION_CHANGE and invert the relationship between Product and Offer, the only other partial Envers' solution I see might be to introduce some attribute on Product that is audited that your business tier couldchange when an offer is modified, causing the Product to be audited like the following: entityManager.getTransaction().begin(); changedOffer.setCode( "NEWCODE" ); changedOffer.getProduct().pulse(); // updates a field to trigger revision entityManager.merge( changedOffer ); entityManager.getTransaction().commit(); Hope this helps. Chris