1 Reply Latest reply on Oct 24, 2008 3:35 AM by Adam Warski

    Envers - Are these Issues?

    Venkat Forums Newbie

      Hi Adam,

      By following up your notes/forum I was able to configure the envers in Spring+Hibernate 3.2.x+envers.1.0.0.ga+Oracle environment.

      I still owe you a "Quick Start" guide for Spring/above environment.

      Here are the current issues that I am facing with and I am not sure if these are Envers issue or not. Can you please clarify.

      Case: I am building entity version for my Account Entity

      1. My Account class has many-to-one relation ship with entity AccountType which is a type table. As it is a type table(always constant), I dont have the need of entity versioning for this. I get the below error message in this case.

      org.hibernate.MappingException: A versioned relation to a non-versioned entity com.package.name.*.AccountType!

      2. We use specialized data type by extending the existing data type. For example, Date class, we have our own version CTSCalendarDate/CTSCalendarDateType. In *.hbm.xml files we use this type instead of Date. This field is Oracle Date type in table/database. Will Envers support this. Currently, I am getting the below exception.
      org.hibernate.MappingException: Could not determine type for: CTSCalendarDateType, at table: ACCOUNT_VERSIONS, for columns: [org.hibernate.mapping.Column(INSERTED_DT)]

      3. I tried to use my @RevisionEntity as we are in Oracle environment. Below is my class. For some reason this class is not detected by envers and it was still using _revisions_info. Do I need to create a bean for this class and inject to some other beans?. Currently, this class was not recognized by Envers in my environment.

      package com.package.name;
      import javax.persistence.Column;
      import javax.persistence.Entity;
      import javax.persistence.GeneratedValue;
      import javax.persistence.Id;
      import javax.persistence.Table;
      import org.jboss.envers.RevisionEntity;
      import org.jboss.envers.RevisionNumber;
      import org.jboss.envers.RevisionTimestamp;
      @Table(name="REVISIONS_INFO") // any name you like
      public class ExampleRevEntity {
       @GeneratedValue // any auto-generated value is ok
       private int id; // can also be a Long
       private long timestamp;
       public int getId() {
       return id;
       public void setId(int id) {
       this.id = id;
       public long getTimestamp() {
       return timestamp;
       public void setTimestamp(long timestamp) {
       this.timestamp = timestamp;
       public boolean equals(Object o) {
       if (this == o) return true;
       if (!(o instanceof ExampleRevEntity)) return false;
       ExampleRevEntity that = (ExampleRevEntity) o;
       if (id != that.id) return false;
       if (timestamp != that.timestamp) return false;
       return true;
       public int hashCode() {
       int result;
       result = id;
       result = 31 * result + (int) (timestamp ^ (timestamp >>> 32));
       return result;

      If you could modify/remove the underscore from VersionsEntitiesConfiguration.java as
      verEntCfg.revisionsInfoEntityName = "revisions_info"

      I believe Oracle database can also work with the default setting.


        • 1. Re: Envers - Are these Issues?
          Adam Warski Master


          1. There is already a JIRA issue for that: https://jira.jboss.org/jira/browse/ENVERS-45. Currently Envers requires that if a relation is versioned, both ends (entities) should be versioned as well. However I agree that your use case is very natural so this should be added as an option.

          2. So you use a custom type? What class do you extend to implement the types?

          3. That's weird ... the detection of @RevisionEntity classes is done at the same time as the detection of @Versioned classes. Is the table REVISIONS_INFO created/present in the database? No other errors/warnings in the log?

          I wish I could change the default revision info table name, but it would break backward compatibility. Maybe in 2.0 :).