I have a bit of a thorny problem. I am porting a music notation application I developed with hand-coded MySQL to Hibernate. The annotations, SQL-generation, etc. are working great, but I'm not sure how to approach a crucial part of the design. I am trying to create continuous persistence whereby all previous states of the object are persistent and easily queryable. (this is for a single-user database)

In the existing application, each object (note, staff, score, etc.) has a key. This never changes during the lifecycle of the object (similar to a primaryKey). When any change is made to the object (ex. a note's pitch is changed), the previous record is marked as dead with a process id, and a new record with the same key is entered with a process id. The process table contains timestamps. By comparing the various versions of the object sharing the same key, it is possible to track edits to that object. (in the case of the research I am doing, the timing of that is significant) In the database, each row has a unique, generated primaryKey value as well, so that it is possible to identify the different iterations of the object.

Some of this could be implemented through rollbacks, but this affects the ability of the user to query the database across time, and seems like a poor way to do this.

I've read through most of the Java Persistence for Hibernate book, and I'm wondering if this is something that I could implement with interceptors, but it seems like it would also strongly affect the querying of objects. Would a composite key be of use? (with a base that is fixed like the Id usually is, but a version number that changes?)

Has anyone done/seen something like this? I certainly don't want to reinvent the wheel, but haven't had much luck finding material on this approach, but it probably has been done.