Can I mark an field as not audited even though the object of the field is an audited entity?

[scdf]

Firstly, apologies if this is a bug that has been fixed. Due to the app container I will be deploying into I have to use an old version of Hibernate before Envers was shipped with it, which means I'm using 1.2.2.GA-hibernate-3.3 of envers, with no better option in sight.

So anyway, I'd like to be able to do something like this:

@Audited
public class Foo {
     /* some other audited data */

     @Audited(targetAuditMode = RelationTargetAuditMode.NOT_AUDITED)
     private Bar latestBar;
}

@Audited
public class Bar {
     /* some audited data */
}

So I want to be able to audit the Bar class as you'd expect. And I'd like to audit the Foo class, as you'd expect. However, I want the latestBar field to not be audited.. in the sense that it shouldn't go get the data for Bar out of the bar_aud table, but instead should get it from the Bar table.

Is this possible, or am I doing something specific enough that it's completely incompatible with a generic framework such as this?

[sacortes]

Hi,

I need the same thing... Have you found some good solution?

By the moment, in my particular case, that is "Showing historical data", my only solution is using duplicate clases (and duplicate mappings with the same tables) with a limited amount of attributes (only showed), but i don't like it too much:

@Audited

class Foo2

    @Audited(targetAuditMode = RelationTargetAuditMode.NOT_AUDITED)

    Bar2 latestBar

// Not audited

class Bar2

Thanks in advance,

Sebastian

[adamw]

Just annotate the field as @NotAudited, note though that upon retrieving historical data, the field's value will be null. There is no way to get historical data which points to the "latest" version.

Adam

[scdf]

"There is no way to get historical data which points to the "latest" version."

Right, so in other words, there is no way to do what I want to do.

In the end I decided to just attach to the historical version of the data. In my particular use-case it's conceptually incorrect but won't make a different to the users. Perhaps for other people a workaround would be do it yourself manually-- take the historical version and then use that to load the latest version.

[hltbdivl]

I've run into a very similar issue, and was confused by the documentation. Here is my data model:
{code}
@Audited
public class Foo {
    ...
   @Audited(targetAuditMode = RelationTargetAuditMode.NOT_AUDITED)
    private Bar latestBar;
}
public class Bar {
    ....
   @Audited
    private String someField;
}
{code}
Note the difference: only one field in Bar is audited. 
Now, the relevant snippet of the documentation says:
{quote}
If you want to audit a relation, where the target entity is not audited (that is the case for example with dictionary-like entities, which don't change and don't have to be audited), just annotate it with@Audited(targetAuditMode = RelationTargetAuditMode.NOT_AUDITED). Then, when reading historic versions of your entity, the relation will always point to the "current" related entity.
{quote}
So I expected that querying for Foo, then traversing foo.latestBar would yield, as the name suggests, the "current" related Bar. What's actually happening is that I get a Bar that's entirely null save for its ID and its someField. Meaning, Bar's proxy initialization is being satisfied by historical data, not by current data.
Reading the docs again, I see that they qualify the behavior with "where the target entity is not audited". They don't explicitly state the behavior for when it is audited, and I think they should: you'll only get current data if none of the target entity's fields are audited.
Come to think of it, I don't see how targetAuditMode is useful. The presence or lack of an @Audited() annotation on the target entity already determines whether that entity is audited; doesn't that make targetAuditMode redundant?
On a related note, another section of the docs say:
{quote}
The main limitation of the current queries implementation is that you cannot traverse relations. You can only specify constraints on the ids of the related entities, and only on the "owning" side of the relation. This however will be changed in future releases.
{quote}
Yet I seem to be traversing queries just fine: querying for Foo and then traversing through foo.latestBar yields a historical Bar. So how exactly is traversing unsupported?

[adamw]

In your model, Bar is audited (an entity is audited if at least one field is audited), so you shouldn't use RelationTargetAuditMode.NOT_AUDITED. It won't work for audited entities, probably hence the weird behavior you are seeing.

Adam

[hltbdivl]

Adam Warski wrote:

In your model, Bar is audited (an entity is audited if at least one field is audited), so you shouldn't use RelationTargetAuditMode.NOT_AUDITED. It won't work for audited entities, probably hence the weird behavior you are seeing.

Adam

Agreed, I see this now. I was just hoping the documentation could be changed to clarify this. Though my original presumption still stands: targetAuditMode seems redundant to me, because @Audited on the target entity will already determine whether that entity gets audited or not.

[adamw]

Docs always need improving, it would be great if things can be explained more clearly; maybe you could create a pull request on github? (you can edit it straight from the browser).

By default Envers throws an exception if there's an audited relation from an audited entity to a non-audited entity, as in most cases this is a mapping error; targetAuditMode is to specify an exception to this.

Adam

[pelu]

I'm also desperately trying to find some kind of tolerable solution that would allow me to have a link from an audited entity to the current version of another audited entity. So this seems to be quite a common need. In my case both of the entities are part of an inheritance hierarchy and I need to perform Envers queries against them which return possibly hundreds of results, so duplicating classes or changing references after the queries have already returned wrong references are far from ideal solutions.

So if somebody has found some sort of annotation combination, hack or even a way to patch Envers to handle this, I would really like to hear about it.

[stigrv]

If not a change in how targetAuditMode is read by the library, then a new annotation that lets you link to the current version of an entity would be desired.

[an_sush]

I am looking for a similar solution as pelu is expecting. Anyone has solution for the same?

[adamw]

Create an issue in JIRA and vote (unless the feature request is not already there).

Adam