org.hibernate.MappingException: property [id.companyId] not found on entity

Hibernate ORM
#1

Hi,

I am in the process of upgrading from Hibernate 5.0 to 5.3 and I am running into an unexpected issue.

My Entity class looks like this:

@Entity
@Table( name="USER_CUSTOMER_MAPPING",
	uniqueConstraints={ @UniqueConstraint( columnNames={ "USER_NAME", "COMPANY_ID", "CUSTOMER_ID" } ) })
@IdClass( UserCustomerMappingId.class )
public class UserCustomerMapping implements Cloneable, Serializable
{
	@Id
    @Column( name="USER_NAME", nullable=false, updatable=false )
    @Index( name="USER_CUSTOMER_MAPPING_USER_NAME_INDEX" )
    @NotNull
    private String userName = null;

    @Id
    @Column( name="COMPANY_ID", nullable=false, length=100 )
    @Index( name="USER_CUSTOMER_MAPPING_COMPANY_ID_INDEX" )
    @NotNull
    @Length( max=100 )
    private String companyId = null;

    @Id
    @Column( name="CUSTOMER_ID", nullable=false )
    @Index( name="USER_CUSTOMER_MAPPING_CUSTOMER_ID_INDEX" )
    @NotNull
    private String customerId = null;

  // rest has been abbreviated for brevity
}

My composite key class looks like this:

public class UserCustomerMappingId implements Cloneable, Serializable
{
    /**
	 * 
	 */
	private static final long serialVersionUID = 1L;
	
	private String userName = null;
    private String companyId = null;
    private String customerId = null;

    public UserCustomerMappingId()
    {
    	super();
    }

  // getters and setters omitted for brevity
}

The above works perfectly on 5.0, but encounters the below MappingException when run deployed on 5.3. This occurs while the PersistenceUnit is starting.

org.hibernate.MappingException: property [id.companyId] not found on entity [...UserCustomerMapping]

I have made no other source nor configuration changes, What am I missing or do I need to change to make the above work with 5.3 please?

#2

Kindly nudged as I am still stuck on this.

I have checked and doubled checked that all of the properties are identically declared between the @Entity and the @IdClass. I am not sure why it is looking for the companyId as a sub-attribute of “id” as there is no “id” in either the @Entity or @IdClass.

Is there any way to get Hibernate to provide more specific information regarding the specific source of the error (i.e. where it is looking for id.companyId from)?

Any and all help will be greatly appreciated.

#3

Have you tried using Hibernate 5.4 already? Maybe this is a bug that was fixed already, just not backported to 5.3. If you still see this issue on 5.4, please create an issue in the issue tracker(https://hibernate.atlassian.net) with a test case(hibernate-test-case-templates/JPAUnitTestCase.java at master · hibernate/hibernate-test-case-templates · GitHub) that reproduces the issue.

#4

Helo @beikov I got a hibernate bug after adding Index annotation with hibernate 5 ,but was working fine with hibernate 4 , I created a jira issue [HHH-14534] Hibernate index causing Runtime failure - Hibernate JIRA , can you take a look please
Thank you

1 Like
#5

I have recently discovered that the org.hibernate.MappingException can be avoided if I remove the @Index annotation from the @Id attributes in the @Entity class. This combination if @Id and @Index has worked well for me in Hibernate 5.0, but appears to be problematic in 5.3 (albeit not so obviously by the error message).

Can anyone shed any light on why this combination is now an issue? Additionally, I want t have a named index on these columns, how can I restore the combination of the two annotations without encountering the MappingException?

#6

I would still like to understand why the combination of @Id and @Index is no longer working. However, I have found a way to still declare the desire to have these indexes by specifying them as part of the @Table annotation.

#7

As you can read in the issue ([HHH-14534] Index annotation causing Runtime failure - Hibernate JIRA) using @Table is the way to go and also a description of why this stopped working. Since the Hibernate @Index annotation is deprecated you should move away from this approach anyway.