I have a legacy database which has a central table of re-usable, user-configurable GenreCodes, which has no primary key but is unique across code and type:
Code:
@Entity
@Inheritance(strategy=InheritanceType.SINGLE_TABLE)
@DiscriminatorColumn(name = "codetype")
@IdClass(CodeId.class)
public class GenreCode {
@Id
private String code;
@Id
@ManyToOne
@JoinColumn(name="codetype")
private GenreGroup codetype;
}
This class has a primary key class
Code:
public class CodeId implements Serializable {
private String code;
private GenreGroup codetype;
}
Any entity that needs to refer to it however, only has a column for ONE of the composite key fields (code). The codetype is unavailable. In the legacy system, this missing type information is spread about and krufts up the business logic. Ideally I would like to define the missing type statically as a literal, so each Entity needs to know what type of code it is using for its coded fields. I tried to implement this using only the subclassing, but it doesn't seem like the discriminator column is used in the join condition.
After a lot of research, I came up with this:
Code:
@Entity
public class Book {
@Id
private Integer id;
@ManyToOne
@JoinColumnsOrFormulas({
@JoinColumnOrFormula(formula = @JoinFormula(value = "'DETECTIVE'", referencedColumnName = "codetype")),
@JoinColumnOrFormula(column = @JoinColumn(name = "CATEGORY", referencedColumnName = "code"))
})
private GenreCode category;
}
This works (thanks team!) as expected. However, in order to use this I had to pull down a 3.5-SNAPSHOT. This is a little too close to the bleeding edge for me, so I'm wondering if there is something in 3.4 that I'm missing (quite likely) that could accomplish the same thing. I understand that this has been possible using xml mappings for some time, but due to the widespread use of these coded fields, we would have to replace nearly all annotation based mappings with xml; something my superiors have directed me to avoid.
All I really want to do is provide a static condition to be added to the @ManyToOne. I'm also trying to minimize the impact to the legacy database, so adding additional relationship tables that fill in the missing key material is possible but costly.
Login
FAQ
Search