I can see the confusion. Hibernate has a similar annotation for
optimistic locking which nearly matches "Versioned" in Envers.
Some "Version"-free class naming ideas:
RevisionListener
VersionsReader -> RevisionReader | HistoryReader
Classes
DefaultRevisionEntity
VersionsReaderFactory -> RevisionReaderFactory | HistoryReaderFactory
Enums
ModificationStore
RevisionType
Annotation Types
RevisionEntity
RevisionNumber
RevisionTimestamp
SecondaryVersionsTable -> SecondaryRevisionsTable | SecondaryHistoryTable
SecondaryVersionsTables
Unversioned -> Unrevised | Untracked ?
Versioned -> Revised | Historical
VersionsJoinTable -> RevisionJoinTable | HistoryJoinTable
VersionsTable -> RevisionTable | HistoryTable
Envers -> Enrise -> Enhist ?
On Wed, Oct 22, 2008 at 6:36 AM, Steve Ebersole <steve(a)hibernate.org> wrote:
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.
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.