-->
These old forums are deprecated now and set to read-only. We are waiting for you on our new forums!
More modern, Discourse-based and with GitHub/Google/Twitter authentication built-in.

All times are UTC - 5 hours [ DST ]



Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 1 post ] 
Author Message
 Post subject: Technical historization
PostPosted: Fri Nov 23, 2012 10:23 am 
Newbie

Joined: Fri Nov 23, 2012 6:37 am
Posts: 1
Hi,

I was looking for a solution that is able to transparently perform technical historization. Technical historization differs from an auditing solution like Envers - technical historization shall give the user transparent access to entities and their relations to any point of time in the past. For example: read the state of database as it was at June, 15th 8:26pm.

"Transparently" means that the user does not need any special API to perform DML operations via HQL, Criteria-API, Session and EntityManager interfaces.
Another requirement is that the entity "designer" can decide whether both current and historic data shall be in a single table or whether current and historic information shall be persistet in two different tables.
Effort for the entity "designer" shall be limited to add some (few!) annotations to entities and maybe relations.

I evaluated Envers for this issue but it does not support transparent access to audited entities. Even though Envers cannot provide both a single and dual table solution, because it is a pure auditing tool.

Since I did not find any working solution that fulfills our requirements I started coding our own solution which basically replaces (extension was not always possible) the Hibernate persisters.
As of today we are still coding the stuff - but 80% works fine. This means that we are able to insert/update/delete/fetch/query data - even across entities that have different historization preference (not-historized, historized using a single table, historized using two separate tables).

In order to let the community share our code and to avoid additional effort due to future api changes we are thinking about making the project open source. If this is not desired we would at least be happy if certain internal hibernate classes could be modified slightly - starting with less restrictive modifiers - which could avoid copy paste code that we had do do in order to integrate out additional features. We would of course help to to integrate and harmonize the code. We have coded our integration using Hibernate 4.1.7.

What do you think?

Robert


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 1 post ] 

All times are UTC - 5 hours [ DST ]


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.