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
steve(a)hibernate.org
Principal Software Engineer
JBoss, a division of Red Hat
http://jboss.com
http://redhat.com
steve.ebersole(a)jboss.com
steve.ebersole(a)redhat.com
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.