Hi All, I am trying Exercise no 8.2 from the book Enterprise Javabeans 3.0(Oreilly). I encountered a weird behaviour . I cannot assign @Generated Value to the primary key of my Super Class while implementing the InheritenceType.TABLE_PER_CLASS mappings. package com.titan.domain;
: Cannot use identity column key generation with <union-subclass> mapping for: om.titan.domain.Employee I Depend On: jboss.jca:service=DataSourceBinding,name=DefaultDS Depends On Me: jboss.j2ee:jar=titan.jar,name=DataAccessBean,service=EJB3
ObjectName: jboss.j2ee:jar=titan.jar,name=DataAccessBean,service=EJB3 State: NOTYETINSTALLED I Depend On: persistence.units:jar=titan.jar,unitName=titan
--- MBEANS THAT ARE THE ROOT CAUSE OF THE PROBLEM --- ObjectName: persistence.units:jar=titan.jar,unitName=titan State: FAILED Reason: javax.persistence.PersistenceException: org.hibernate.MappingExceptio : Cannot use identity column key generation with <union-subclass> mapping for: om.titan.domain.Employee I Depend On: jboss.jca:service=DataSourceBinding,name=DefaultDS Depends On Me: jboss.j2ee:jar=titan.jar,name=DataAccessBean,service=EJB3
I know I'm a little late, but maybe this answer will help somebody anyways.
One cannot use IDENTITY for primary key generation strategy with conjunction with "table per concrete class" inheritance, because in such a case the identity column must be present in each table and its values must be mutually exclusive: in a case of auto-generated value we say that they must share a seed. For example, for the hierarchy proposed in the original post:
So it is clearly not possible to use IDENTITY generation strategy, because it cannot guarantee that e.g. value 3 won't appear in any other table but EMPLOYEE.
If the generation strategy isn't specified in @GeneratedValue annotation, GenerationType.AUTO is assumed which means that the persistence provider is free to choose whichever strategy it likes, IDENTITY included. So only specifying SEQUENCE or TABLE strategies will ensure portable behaviour.
EDIT: shortened horizontal bars that looked bad due to line wrapping
TABLE strategy for key generation is always available, because it can be performed by the persistence provider on its own (i.e. by performing SELECTs and INSERTs on a designated table). It is by far the most portable and flexible choice, but for some databases it's suboptimal performance-wise.
Is it possible to use TABLE_PER_CLASS strategy where each subclass has its own native generator ?
Maybe I can supply the same SEQ for both subclasses to make sure I will have mutually exclusive IDs.
My super class it's abstract and I do not really need a table for it.
SCJP 1.6, SCWCD 1.5
Men call me Jim. Women look past me to this tiny ad:
a bit of art, as a gift, the permaculture playing cards