|keeping a history [message #389725]
||Wed, 24 June 2009 07:24
| Tom Eugelink
Registered: July 2009
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.
Powered by FUDForum
. Page generated in 0.10185 seconds