| keeping a history [message #389725] |
Wed, 24 June 2009 07:24  |
 Tom Eugelink
Messages: 817
Registered: July 2009 |
Senior Member |
|
|
So I'm using Informix, and even though it technically is a very good database, there are some serious shortcomings. I will not start a rant about the "so 80ties" way of managing the server, because Eclipselink cannot help there much. However, maybe in the area of keeping a changelog Eclipselink can. Informix AFAIK offers only a functionality that logs the internal row id of a changed record, not the actual fields.
Does anyone have insights in how to best keep a changelog of the database?
ATM I have a JDBC program running each night, analyzing record-by-record if any field has changed and then making a copy to a table in a separate database with an additional timestamp in the key. This works ok, but is very time consuming and getting more so by the day. Especially detecting if a record is deleted.
1. I naturally could track all changes to each property of an entity in my BM and write "table,key,property,by,date: old -> new" records in the @PostSave. But that is very very space consuming and not really reusable.
2. I could create a mirror database with an additional timestamp in the key of every table and without references. But how would I go about accessing that without duplicating my whole BM? It would be great if I could simply extend an @Entity class and override the PK, but I cannot.
This approach still is possible if I use one of the repackaging tools, copying my whole BM to another package and then add that additional private key.
3. I could log all changed records "table,key,action" in a logtable during daytime, and then -based on that data- have an optimized JDBC programm copying those changed records.
4. Eclipselink could have a feature where every JDBC insert or update statement is caught and offered to a post-processing logic.
5. I could extend my logging JDBC driver classes and add a similar post-processing logic. But that would require me to parse the SQL, while with the Eclipselink post processing the SQL statement already is interpreted as Java classes.
ATM I'm leaning towards attempting #2.
Tom
|
|
|
| Re: keeping a history [message #389738 is a reply to message #389725] |
Thu, 25 June 2009 13:26  |
|
EclipseLink has history support that may meet your requirements. This
allows for a mirror history table to be kept for each table, which
includes a timestamp and a row for any change to the primary table.
See,
http://wiki.eclipse.org/Configuring_a_Descriptor_(ELUG)#Conf iguring_a_History_Policy
EclipseLink also has an extensive event mechanism including and beyond JPA
events provided through DescriptorEventsListener and SessionEventListener.
You could look into the pre/post/aboutToUpdate events and the ChangeSet
API.
---
James
http://www.nabble.com/EclipseLink---Users-f26658.html
James : Wiki : Book : Blog : Twitter
|
|
|
|
| Re: keeping a history [message #496296 is a reply to message #389725] |
Mon, 09 November 2009 15:57 |
|
There is currently no annotations support for history (please log an enhancement), so you need to use the ClassDescriptor API.
You can access the ClassDescriptor using a DescriptorCustomizer, which you can set using the customizer persistence.xml property, or @Customizer annotation.
James : Wiki : Book : Blog : Twitter
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.01906 seconds
Search
Help
Register
Login
Home
