Audited relations lazy by default?

[flexpert]

I just realized that an entity instance loaded by the AuditReader has its audited relations set to lazy even if the FetchType on the defining entity is marked as EAGER. E.g. on an audited class Notif there's an audited relation to the audited class Country which is marked as EAGER:

@Audited
@ManyToOne(fetch = FetchType.EAGER)
@JoinColumn(name = "country_id", nullable = false)
public Country getCountry()
{
  return this.country;
}

So - when loading a Notif object by the entityManager, the country is fetched eagerly. However, when loading a historic Notif object by using the AuditReader, the country property is an uninitialized Javassist proxy.

Is there any way to make Envers respect the FetchType specified on the "original" entity?

Dirk

[adamw]

Hello,

that's a known issue, already reported in jira (and not solved yet). The problem here is that even if the relation was fetched "eagerly", then it would still be 2 queries. Fetching all in one query will be possible after end-revision column will be implemented.

Adam

[flexpert]

ok, I see.

I wanted to use some sort of generic method in a service bean that loads an entity revision but for now I'll workaround this by adding concrete methods that will initialize the lazy properties similar to those of a "real" entity (we use Envers in a web application with a Flex frontend so we have to populate lazy proprties before they get serialized)

Thanks!

Dirk.

[adamw]

Hello,

if you want to pursue another pass, I think that adding eager-loading to Envers shouldn't be too hard.

Maybe this could be configurable via a configuration proprerty.

Adam

[flexpert]

Hi Adam,

well it's not so much about eager loading per se. I was hoping that an revisioned entity would "behave" similar to an unrevisioned entity in terms of how relations are fetched / initialized.

E.g. it would be cool if the revision of an entity A with an lazy loaded relation b to entity B and an eagerly loaded relation c to entity C would have its relations initialized if they were EAGER and not initialized if they were defined as LAZY on the entity.

I just started with Envers a week ago so I do not know too much yet of how things set up internally but my first guess would be that during the setup of Envers the Audited entities would have to be scanned for the fetchType defined on the relations and these settings should then also apply to the generated Envers Proxies...

Dirk.

[flexpert]

after some research I found that the data fetched from the auditing tables gets mapped to the entities inside the EntityInstantiator by the various org.hibernate.envers.entities.mapper.PropertyMapper implementations.

So the place to initialize lazy collections/proxies based on the original entity configuration is possibly somewhere there, right?

Dirk

[adamw]

Hello,

yes, that's exactly the place If the relation is EAGER, then the value should be fetched right away, instead of creating a proxy.

Adam

[oxyde42]

hey,

is there any new developpement regarding this bug ?

Thank you