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(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 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