Deleted entities with null properies - WHY?

[agorski]

Hallo,
in the documentation there is an information that audits entries for deleted entities have got null valued properties except of ID.

My question is why it is so?

Real live example:
there is a system which stores client data in CLIENT table. Client data are valid for a year and after this period should be removed (performance reason).
BUT it must be a possibility to:
- query archived data
- show client data in "normal" manner using existing software (UIs)
- print client data
- !!! History of changes is not necessary !!!

In such case it is reasonable to audit/listen ONLY delete actions. Problem is that such audit entries are empty :(

greetings,
Albert

[adamw]

Hello,

the reason is because the revision stores the "current" state, as it was at that revision; when you delete an entity, it has no state (as its deleted). The solution to your problem would be to audit ADD and DEL actions (not MOD actions) (so just install insert/delete listeners, not the update ones). Then, the history of each entity would have 1 or 2 entries, and the first entry would hold the original data.

Adam

[agorski]

Hi,
I cannot use first entry to solve my problem - entry could change during its live and for me important is only last state of the entry (actual shortly before delete).

Of course there is a way around to keep MOD entries and after delete remove all MOD except newest one but this solution is dirty.

You said revision stores "current" state - I think listeners are connected to Post(Remove/Create/Update) actions - maybe for the delete action would be better to connect listener with PreRemove ?

Albert

[adamw]

Hello,

ah yes, you are right of course. Then it's a simple code change, if you look at the envers code (AuditEvenListener). I think you simple need to schedule ModWorkUnit instead of a DelWorkUnit in the on delete listener.

Adam

[agorski]

Hello,

of course I can change the code but still remains the question if it is only my problem/wish or general one.
I think it would be much better to keep last state before delete in opposite to keep only ID of removed entity.

The problem with keeping only ID is much deeper: imagine that you logging only DEL events. You are not able to query/filter your data unless you use ID (from user perspective unacceptable). What more even if you find audit data it keeps only information when entry was removed.

regards,
Albert

[adamw]

Hello,

maybe it can be a configuration option. Normally I think it's not desired (if you audit all events), as then the last state would be duplicated in the last mod revision and the del revision.

But in fact, maybe adding this as an option isn't a bad idea. I could also add a section to the manual describing how you can audit only certain types of events.

If you still support the idea, please create a jira feature request :). Maybe also some other users will give feedback?

Adam

[kaizersh]

Hi,

I'd made a post sometime back regarding the same thing. It would actually be good to have the option to store the fields of the entity to be deleted in the audit table. We have a scenario where we would need to retrieve the state of an entity as it existed at time of deletion. Currently, I would have to get the state based on the last modified revision.

Thanks.

Regards
Kaizer

[adamw]

Ok, great, that's two votes :) Please create a feature request in JIRA.

Adam

[agorski]

Hi,
already done:
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3819

Have a nice implementation :)

Albert

[adamw]

Thanks ;)

Remember that contributions are always welcome and often speed up significantly introducing a new feature ;)

Adam