Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » EclipseLink » keeping a history
keeping a history [message #389725] Wed, 24 June 2009 07:24 Go to next message
Tom Eugelink is currently offline Tom EugelinkFriend
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 Go to previous messageGo to next message
James Sutherland is currently offline James SutherlandFriend
Messages: 1939
Registered: July 2009
Location: Ottawa, Canada
Senior Member

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 #496286 is a reply to message #389738] Mon, 09 November 2009 15:45 Go to previous messageGo to next message
Tom Eugelink is currently offline Tom EugelinkFriend
Messages: 817
Registered: July 2009
Senior Member
I'm attempting to activate history on my JPA entities.

> http://wiki.eclipse.org/Configuring_a_Descriptor_(ELUG)#Conf iguring_a_History_Policy

But the examples refer to an employeeDescriptor; is there a way for me to get to such descriptors for my JPA entities?

Tom
Re: keeping a history [message #496296 is a reply to message #389725] Mon, 09 November 2009 15:57 Go to previous messageGo to next message
James Sutherland is currently offline James SutherlandFriend
Messages: 1939
Registered: July 2009
Location: Ottawa, Canada
Senior Member

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
Re: keeping a history [message #496311 is a reply to message #496296] Mon, 09 November 2009 16:45 Go to previous messageGo to next message
Tom Eugelink is currently offline Tom EugelinkFriend
Messages: 817
Registered: July 2009
Senior Member
Annotation support would not be needed, it would suffice if the ClassDescriptor can pick my entity class and keep a history (without me having to specify all fields and mappings).

James wrote:
> 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.
>
Re: keeping a history [message #499843 is a reply to message #496296] Tue, 24 November 2009 11:07 Go to previous messageGo to next message
Tom Eugelink is currently offline Tom EugelinkFriend
Messages: 817
Registered: July 2009
Senior Member
James wrote:
> There is currently no annotations support for history (please log an
> enhancement), so you need to use the ClassDescriptor API.

Bug 295982 has been added to the database
Re: keeping a history [message #499857 is a reply to message #496296] Tue, 24 November 2009 11:48 Go to previous message
Tom Eugelink is currently offline Tom EugelinkFriend
Messages: 817
Registered: July 2009
Senior Member
> You can access the ClassDescriptor using a DescriptorCustomizer, which
> you can set using the customizer persistence.xml property, or
> @Customizer annotation.

According to the documentation (http://wiki.eclipse.org/Using_EclipseLink_JPA_Extensions_(ELUG)) this would be correct:
propertiesMap.put(PersistenceUnitProperties.DESCRIPTOR_CUSTO MIZER+ ".Order", "acme.sessions.MyDescriptorCustomizer");

However "PersistenceUnitProperties.DESCRIPTOR_CUSTOMIZER" does not exist (in 1.1.3), what does exist is the id with an additional underscore at the end. But that version never calls the method (naturally I provided my own class implementing org.eclipse.persistence.config.DescriptorCustomizer).
The simple version does not call either:
propertiesMap.put(PersistenceUnitProperties.DESCRIPTOR_CUSTO MIZER, nl.reinders.bm.support.Customizer.class.getName());

The annotation works:
@Customizer(nl.reinders.bm.support.Customizer.class)

So I'm able to get to the information. Just wanted to let you know that the documentation does not match what I can do. Or is this a 1.2 thing?

Tom
Previous Topic:Import Schema error
Next Topic:Unsatisfied import package javax.lang.model.type
Goto Forum:
  


Current Time: Tue Mar 19 03:06:44 GMT 2024

Powered by FUDForum. Page generated in 0.03376 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top