[hibernate-dev] Envers: Mapped-superclasses extended by embeddabables

Steve Ebersole steve at hibernate.org
Tue Jun 3 09:17:43 EDT 2014


I just want to make sure this is consistent across uses.  What are the
rules for Audited, MappedSuperclass and Entity?  IMO, that is what should
happen for Audited, MappedSuperclass and Embeddable as well.  Are those
consistent?

Adam, what specifically is complicated by supporting AO paths?  Is it
handling the path and targeting the proper attribute?  Or is it that envers
assumes composites are either audited or not in total?  Allowing paths here
would be much more natural/consistent with regard to
AttributeOverride/AssociationOverride.


On Fri, May 30, 2014 at 1:39 AM, Gail Badner <gbadner at redhat.com> wrote:

> Hi Adam,
>
> Currently, the ways to enable auditing on a mapped-superclass that  we
> discussed below do not work when an embeddable class has no declared data.
> The only way I can find to enable auditing for the mapped-superclass is to
> annotate the embeddable class with @Audited.
>
> For example:
>
> @Entity
> @Audited
> public class A{
>   ...
>   private B b;
>   ...
> }
>
> @Embeddable
> @Audited // currently, this must be here in order for the
> mapped-superclass to be audited
> public class B extends AbstractB {
>   // no declared data
> }
>
> @MappedSuperclass
> @Audited // does nothing due to HHH-9193, but will be required after
>          // HHH-9193 is fixed, unless there is an @AuditOverride
> public class AbstractB {
>   private String strValue;
> }
>
> Annotating the embeddable class makes it work, but does this really make
> sense? Is this a reasonable workaround? Could this cause problems in future
> versions?
>
> The test case attached to HHH-8908 illustrates this.
>
> Thanks,
> Gail
>
> ----- Original Message -----
> > From: "Adam Warski" <adam at warski.org>
> > To: "Gail Badner" <gbadner at redhat.com>
> > Cc: adam at hibernate.org, "Hibernate" <hibernate-dev at lists.jboss.org>,
> "Łukasz Antoniak" <lukasz.antoniak at gmail.com>
> > Sent: Tuesday, May 20, 2014 9:45:28 PM
> > Subject: Re: Envers: Mapped-superclasses extended by embeddabables
> >
> > Sorry, no idea why I missed that email.
> >
> > So the basic rule is:
> > - fields from a non-audited mapped superclass are never audited, unless
> an
> > @AuditOverride is specified
> > - if the mapped superclass is audited, then its fields are of course
> audited
> > as well
> >
> > I don’t think we want to get into supporting a @AuditOverride(“b.field”)
> > syntax, as it complicates the whole thing. When an @AO is placed on a
> > component, the names refer to what is inside the component, so I guess we
> > can use it here?
> >
> > To address the specific questions:
> >
> > > In the following, A.b.intValue should be audited; A.b.strValue should
> not
> > > be audited.
> > >
> > > @Entity
> > > @Audited
> > > public class A{
> > >    ...
> > >    private B b;
> > >    ...
> > > }
> > >
> > > @Embeddable
> > > public class B extends AbstractB {
> > >    private int intValue;
> > > }
> > >
> > > @MappedSuperclass
> > > public class AbstractB {
> > >    private String strValue;
> > > }
> >
> > Looks good
> >
> > > In the following, both A.b.intValue and A.b.strValue should be audited:
> > >
> > > @Entity
> > > @Audited
> > > @AuditOverride( name="b.strValue" )
> > > public class A{
> > >    ...
> > >    private B b;
> > >    ...
> > > }
> > >
> > > @Embeddable
> > > public class B extends AbstractB {
> > >    private int intValue;
> > > }
> > >
> > > @MappedSuperclass
> > > public class AbstractB {
> > >    private String strValue;
> > > }
> >
> > As above, I don’t think we want to supoprt @AO(name=“b.strValue”)? To
> audit
> > b.strValue, you’d have to add an @AO(name=“strValue”,
> > forClass=AbstractB.class) on the b field directly.
> >
> > > In the following, both A.b.intValue and A.b.strValue should be audited:
> > >
> > > @Entity
> > > @Audited
> > > public class A{
> > >    ...
> > >    private B b;
> > >    ...
> > > }
> > >
> > > @Embeddable
> > > public class B extends AbstractB {
> > >    private int intValue;
> > > }
> > >
> > > @MappedSuperclass
> > > @Audited
> > > public class AbstractB {
> > >    private String strValue;
> > > }
> >
> > Yes
> >
> > > In the following, both A.b.intValue and A.b.strValue should be audited.
> > >
> > > @Entity
> > > @Audited
> > > public class A{
> > >    ...
> > >    private B b;
> > >    ...
> > > }
> > >
> > > @Embeddable
> > > @AuditOverride( class=AbstractB.class )
> > > public class B extends AbstractB {
> > >    private int intValue;
> > > }
> > >
> > > @MappedSuperclass
> > > public class AbstractB {
> > >    private String strValue;
> > > }
> >
> > Yes
> >
> > > What should be the outcome of the following? Should A.b.strValue still
> be
> > > audited even though A.b is explicitly not audited?
> > >
> > > @Entity
> > > @Audited
> > > public class A{
> > >    ...
> > >    @NotAudited
> > >    private B b;
> > >    ...
> > > }
> > >
> > > @Embeddable
> > > public class B extends AbstractB {
> > >    private int intValue;
> > > }
> > >
> > > @MappedSuperclass
> > > @Audited
> > > public class AbstractB {
> > >    private String strValue;
> > > }
> >
> > @NotAudited has precedence - so not audited.
> >
> > I hope things are a bit clearer :). I suppose we should document these
> rules.
> > If, of course, you think these rules are sound - any other ideas are
> always
> > welcome :)
> >
> > Adam
> >
> > --
> > Adam Warski
> >
> > http://twitter.com/#!/adamwarski
> > http://www.softwaremill.com
> > http://www.warski.org
> >
> >
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>


More information about the hibernate-dev mailing list