Envers fails to audit subclass of @Audited @Entity with @Inheritance

Description

steps to reproduce
  1. have a BaseClass:

  2. and Derived:

  3. persist instance of Derived

expected
  • insertion audited and value of someProperty saved in AUD table

observed
  • nothing audited

  • most probably because isVersioned returns true for BaseClass, but not for Derived in EnversPostInsertEventListenerImpl:

    EnversPostInsertEventListenerImpl

Activity

Show:

Erin Whitla May 12, 2021 at 11:56 PM

I just encountered this issue in 5.4.9. Nothing quite as show stopping as an exception but the cost was higher for us. When attempting to read the audit log for an unannotated subclass of an audited entity we discovered nothing had ever been recorded. Data lost.

Piotr Findeisen July 12, 2016 at 9:55 PM

Ha! Incidentally, I wrote an example close to yours, Chris, in

Piotr Findeisen July 12, 2016 at 9:51 PM

, I fully agree and support your desire for consistency.

Perhaps, a slightly more real-life than abstract "base" and "derived" entities could be helpful in determining what should be the expected behaviour.

Consider an @Entity Car with @Audited property – owner – and not audited ones – numberOfSeats, color. Since owner and plates are very important pieces of information, we need to track every change of them, for every Car.

Now, assume we have inheritance here. Car is abstract and has two subclasses. @Entity RegularCar extends Car which adds plates property (that's important, so we @Audit it). And also @Entity SportCar extends Car which adds bunch of other properties: isFormula1Allowed, numberOfWonRaces, timeRequiredToReplaceAllWheelsInNanos. We don't need to audit those properties, hence we don't want any audit-related annotations on a sport car.

Now, every Car has its owner and this property is marked as audited. RegularCar has also plates property marked as audited. So my expectation is that every change to RegularCar.plates gets recorded as well as every change to Car.owner, regardless which of the two subclasses this happens to be.

Chris Cranford July 10, 2016 at 8:33 PM

I'd say that your Derived class doesn't just become an entity simply because it extends from BaseClass. The Derived class must be annotated with several annotations before it will work properly in the persistence framework as desired, so why should auditing be any different?

I think what we first need to decide is foremost what makes the most sense with respect toward consistency.

If we assume that super classes can be annotated but those annotations are only activated based on the state of the root entity of that hierarchy, this allows for providing some default auditing behavior that transitively is enabled if and only if the subclass implementation elects to be audited. Similarly, this same configuration permits audited subclass implementations to disable or modify super class auditing behavior if they so choose using audit overrides.

Whether an entity extends a @MappedSuperclass or another @Entity, how we gather, interpret, and operate on audited metadata should be consistent. To me this closes the potential usage error gap because there is no gray area on whether it works this or that way based on certain entity hierarchy configurations.

As I asked in HHH-6331, please feel free to provide any feedback on this. If we decide to make any changes for this, I'd prefer them in 6.0 or this may need to wait for 7.0 just given the nature of the backward compatibility concerns this could introduce. But presently I'm inclined to view this as working as intended and that subclass entities should be explicitly annotated.

Chris Cranford January 6, 2016 at 2:23 AM

, that would be my understanding. In both cases, it boils down to the examined class having no marker to indicate it should be audited and so the parent hierarchy is ignored.

Assignee

Chris Cranford

Reporter

Components

Affects versions

Priority

Created May 3, 2015 at 11:05 PM
Updated May 12, 2021 at 11:56 PM
Loading...