[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-879?page=co... ] Chris Wilson commented on HHH-879: ---------------------------------- I tried to work around this as suggested by creating more associations. In my case there were logically distinct associations that I could use for querying against, which also simplified the use of criteria, so the effect on code readability was not too bad. However I did struggle because my additional associations caused the dreaded MappingException: {quote} org.hibernate.MappingException: Repeated column in mapping for entity: org.wfp.rita.dao.Movement column: request_line_id (should be mapped with insert="false" update="false") {quote} This is because apparently, if your OneToMany associations are not declared as Inverse, Hibernate Annotations CollectionBinder silently adds {{Backref}} properties which are marked as insertable but not updatable: {code} if ( !collection.isInverse() && !collection.getKey().isNullable() ) { // for non-inverse one-to-many, with a not-null fk, add a backref! String entityName = oneToMany.getReferencedEntityName(); PersistentClass referenced = mappings.getClass( entityName ); Backref prop = new Backref(); prop.setName( '_' + fkJoinColumns[0].getPropertyName() + "Backref" ); prop.setUpdateable( false ); {code} The easy way around this seems to be to make the collections inverse. However, you can't just do this with annotations, because there's no way to set it directly. it's true for mapped associations and false otherwise (see how {{CollectionBinder.bind() calls setInverse(...)}}). I'm not sure why inversion is not the default for OneToMany associations, which are "usually" managed from the Many side (the other side) in any case. I didn't really want to reuse the mapping from the other class, as it's logically inconsistent to have three distinct sets mapped by the same property on the other side, but nor did I want to create three duplicate mappings to work around this bug, so I'm reusing the mapping for now and hoping that it will work. I'm mainly commenting here because this error was not easy to track down, and I wanted to make it easier for others in future, and to provide guidance to those working around this bug by adding associations. -- 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