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 [EMAIL PROTECTED] Principal Software Engineer JBoss, a division of Red Hat http://jboss.com http://redhat.com [EMAIL PROTECTED] [EMAIL PROTECTED] 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 _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
