[ http://opensource.atlassian.com/projects/hibernate/browse/ANN-391?page=co... ] mike wray commented on ANN-391: ------------------------------- We've used a different appraoch to workaround this. Map the secondary table to its own entity, then reference that entity from the first entity using a cascading @onetoone. <code> @Entity public class Primary..... private Second second; @OneToOne(mappedBy="primary", cascade=CascadeType.ALL) private Second getSecond () { if(this.second== null){ this.second= new Second(); this.second.setPrimary(this); } return this.second; } private void setSecond (Second value) { this.second= value; } @Transient public String getExt1() { return getSecond().getExt1(); } public void setExt1(String ext1) { getSecond().setExt1(ext1); } @Entity public class Second.... private Primary primary; @OneToOne public Primary getPrimary () { return this.primary; } public void setPrimary (Primary value) { this.primary= value; } .. </code> You could probably further encapsulate by having Second as a private inner class, haven't tried that - i'm not sure it's allow by jpa. These mappings cause an Outer Join query with SECOND, which is exactly what a @SecondaryTable would do. Creation of a new PRIMARY only inserts a new SECOND row if values are explicitly set for Extension properties, which is exactly what @SecondaryTable would do. CascadeType.ALL means SECOND row is flushed to database at same time as PRIMARY , which is exactly what @SecondaryTable would do. Internal implementation is hidden. The object model and the physical model remain the same. A possible difference:If all properties on SECOND are set to null, SECOND row is not deleted (would @SecondaryTable do that?? - I'm not sure) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira