Since the cubeLocation field is defined within Employee class, the AssociationOverride annotation has to be applied directly to the field definition. Had the cubeLocation field been defined in a MappedSuper class of Employee (say, in Person), you would have to specify AssociationOverride annotation on the class.
When used to override a mapping defined by a mapped superclass, the AssociationOverride annotation is applied to the entity class.
HTH,
Paul.
Yeah but this doesn't say that the only time you're allowed to use AssociationOverride at Class level is with MappedSuperclass. You can use it there for this case also, but you have to use as prefix the name of the field in this class.
When used to override a mapping defined by a mapped superclass, the AssociationOverride annotation is applied to the entity class.
HTH,
Paul.
Yeah but this doesn't say that the only time you're allowed to use AssociationOverride at Class level is with MappedSuperclass. You can use it there for this case also, but you have to use as prefix the name of the field in this class.
Right, the explanation is not saying that either. The explanation is saying that if the field is defined in the mapped super class, you have to use the annotation at the class level. How can you specify the overrides on the field in the sub class if the field is not present there?
If you like our products and services, please help us by posting your review here.
You can use @AssociationOverride annotation on the owner side of the relationship (i.e. the Many side in a ManyToOne/OneToMany relationship, which is Employee in the case), to change the name of the foreign key column. For example: @AssociationOverride( name="cubeLocation.mailBox", //Observe that cubeLocation. is required only if the @AssociationOverride is applied on the class instead of the field because mailBox field is not present directly in Employee. It is accessible through cubeLocation. joinColumns=@JoinColumn(name="MBX_ID") )