Bug 330397

Comment 1 Tom Bailey 2012-09-28 12:13:39 EDT

The documentation should be modified to state this limitation.
http://wiki.eclipse.org/EclipseLink/Examples/JPA/History

It implies this will all be easy and automatically set up. However, you need to create a history entity for every entity you have and then keep them in sync :-(

Comment 2 Tom Eugelink 2013-02-11 05:26:46 EST

This indeed would be a nice addition, because I also often forget to modify the history table. 

One addition to this request; I have chosen to modify the database schema manually, so I've NOT set:
<property name="eclipselink.ddl-generation" value="drop-and-create-tables"/>

This has to do with the fact that not all database changes are simple, but can require complex data migration. However, for history this is not the case, because it simply should store changes. 

So it would be nice if -when this feature is added to Eclipselink- activating this for history tables could be done, even when the normal tables are not automatically generated.
<property name="eclipselink.ddl-history-generation" value="drop-and-create-tables"/>

Comment 3 Clovis Wichoski 2016-01-02 15:29:19 EST

The problem still occurs with 2.6.2

Follow a StringTemplate to be used to easy the creation by hand (for Postgres database)

CREATE TABLE <tableName>_audit (
   LIKE <tableName> EXCLUDING ALL,
   audit_date_start timestamp,
   audit_date_end timestamp
)

Comment 4 Peter Hansson 2016-03-25 05:30:42 EDT

Yes, I've had the same issue.

I've explored a couple of avenues in order to get EclipseLink to generate the history tables for me (so that they always reflect their base table). I haven't been able to come up with a method that would work, less one that would be db agnostic.

I do believe the only way to solve this is in the core of EclipseLink, for example by adding a new annotation, @HistoryTable.


I'm thinking something along the lines of the following: 

Suppose you have base class, Person: 


@Entity
public class Person {

   @Id
   private Long personId;
   private String firstName;
   private String lastName;
   ..
}

Then we could define a history entity for that entity as follows:

@Entity
@HistoryTable(base=Person.class, primaryKeyFields="personId,rowStartTime")
public class PersonHist {

   // Add here the extra fields/columns that should exist for the
   // history table.
   private Date rowStartTime;
   private Date rowEndTime;
   ..
}


The @HistoryTable annotation would replicate all fields from the base entity, including most field annotations, except for annotations related to relations, which wouldn't be relevant on the history table.

By definition the history table's primary key will always be a composite of columns in the base table, typically it will be like in the example. In the example the PersonHist entity will think it has an @Id notation on fields personId and rowStartTime. (yeah, this area needs more brain work :-))


Note: At the moment the EclipseLink History feature doesn't expect the history table to be mirrored in an Entity. It is just pure SQL going on. So it is really all about getting EclipseLink to create the table. The History feature will never as such use the PersonHist class, (almost) the only reason why it exists in my solution is to get EclipseLink to create the table. However it is handy to have a PersonHist entity for other reasons, say for example if you wanted to show visually the contents of the history table in your application.

Comment 5 Eclipse Webmaster 2022-06-09 10:05:59 EDT

The Eclipselink project has moved to Github: https://github.com/eclipse-ee4j/eclipselink