[hibernate-dev] Envers in Hibernate

[Steve Ebersole]

Yes I think it will really lead to confusion.

Deprecation seems reasonable.  So lets get this migrated for Hibernate's
3.4/3.5 release with the deprecations noting removal in 4.0.

-  

Steve Ebersole
Project Lead
http://hibernate.org
steve at hibernate.org

Principal Software Engineer
JBoss, a division of Red Hat
http://jboss.com
http://redhat.com
steve.ebersole at jboss.com
steve.ebersole at redhat.com


On Thu, 2008-10-23 at 10:42 +0200, Adam Warski wrote:
> Hello,
> 
> > I can see the confusion. Hibernate has a similar annotation for
> > optimistic locking which nearly matches "Versioned" in Envers.
> Yes, @Version. But it's for a totally different thing. So far I only  
> once I had a question on the forum if @Versioned and @Version are  
> related in any way. Do you really think it creates confusion?
> 
> > Some "Version"-free class naming ideas:
> >
> > RevisionListener
> > VersionsReader -> RevisionReader | HistoryReader
> The "RevisionXXX" names would suggest that it's for reading revision  
> data, so revision entities, not the acutal historic data. If at all,  
> "HistoryXXX" seems much better (HistoryReaderFactory,  
> SecondaryHistoryTable, HistoryTable, HistoryJoinTable).
> 
> If there would be a name change, then the old classes/annotations  
> should be deprecated, not removed - people wouldn't want to see their  
> code broken after upgrading to a newer version.
> 
> > Unversioned -> Unrevised | Untracked ?
> > Versioned -> Revised | Historical
> There was also the idea of "Historized" :) Then also: Unhistorized.
> 
> > VersionsJoinTable -> RevisionJoinTable | HistoryJoinTable
> > VersionsTable -> RevisionTable  | HistoryTable
> >
> > Envers -> Enrise -> Enhist ?
> I would keep the current name, people got used to it :) And it doesn't  
> directly suggest anything with versioning.
> 
> Adam