I think the "plug in the way versioned data is stored" bit accounts for what I meant :)
Also I suggest that you move away from the term "versioning" here. This is already: 1) over-used/over-loaded 2) used by the JPA spec to mean optimistic locking. Really this is "auditing" or "capturing historical data". If you use IRC, perhaps we could chat about the specifics of pulling your code into the Hibernate svn? irc.freenode.org -> #hibernate-dev - Steve Ebersole Project Lead http://hibernate.org [EMAIL PROTECTED] Principal Software Engineer JBoss, a division of Red Hat http://jboss.com http://redhat.com [EMAIL PROTECTED] [EMAIL PROTECTED] On Wed, 2008-10-22 at 09:07 +0200, Adam Warski wrote: > Hello, > > > One thing I would like to see in adition is the ability to store > > flattened audting of changes. There are many examples of such a thing > > on the wiki and the web at large. > yes, that's one of the points on my roadmap - "support for different > versioning schemes" (provided I have the time to implement it, of > course :) ). The idea is quite simple - you would be able to plug in > the way versioned data is stored, but access it using the same > interface (VersionsReader). > > The versioning scheme that I wanted to add would just store entity > name + entity id + field name + field value combinations. This would > effectively be a simple audit log. Is it what you meant? You could > then access the data as before (with VersionsReader.find, for > example), except that you wouldn't be able to execute queries. > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
