SQL for Index and Foreign Key didn't get generated if I map ID column after @ManyToOne

This issue is kinda strange with an easy workaround to fix it, I’m not sure if that’s an issue though, so the idea is if I have Model that maps another Model and used @JoinColumn to do that mapping (I’m not sure if this is part of issue actually), the SQL script that should be generated only appears if and only if mapping the id column is BEFORE the mapping it with @ManyToOne

I mean this is confusing but here is an example:

Steps to reproduce

If I have UserSubscriptions bean, that bean got Topic, like the following:

@Entity
@Table(name = "UserSubscription", schema = "alerts")
public class UserSubscription extends Model {
    @ManyToOne(optional = false, cascade = {CascadeType.MERGE, CascadeType.PERSIST, CascadeType.REFRESH})
    @DbForeignKey(onDelete = ConstraintMode.CASCADE)
    @JoinColumn(name = "TopicId")
    private Topic topic;

    @Column(name = "TopicId", nullable = false, insertable = false, updatable = false)
    private Integer topicId;

SQL should generate:

create index [ix_UserSubscription_TopicId] on [alerts].[UserSubscription] ([TopicId]);
alter table [alerts].[UserSubscription] add constraint [fk_UserSubscription_TopicId] foreign key ([TopicId]) references [alerts].[Topic] ([Id]) on delete cascade;

But in this case, here it is not working, I have to maintain the order between properties so I have to change my code to:

@Entity
@Table(name = "UserSubscription", schema = "alerts")
public class UserSubscription extends Model {

    @Column(name = "TopicId", nullable = false, insertable = false, updatable = false)
    private Integer topicId;

    @ManyToOne(optional = false, cascade = {CascadeType.MERGE, CascadeType.PERSIST, CascadeType.REFRESH})
    @DbForeignKey(onDelete = ConstraintMode.CASCADE)
    @JoinColumn(name = "TopicId")
    private Topic topic;

In this case, the SQL script showing up.

[jnehlmeier]

In JPA/EclipseLink I used something like that before. Using the above classes as example I think it was along the lines of having a larger list of UserSubscription instances and instead of triggering lazy load by calling getTopic() I collected topicIds and did a query manually. This was a last resort solution to avoid lots of lazy load queries when JOIN FETCH and BATCH FETCH both did not work properly in JPA/EclipseLink.

Sometimes I also used it to optimize a query since EclipseLink usually uses the pattern JOIN subscription.topic t WHERE t.id = :id instead of just WHERE subscription.topicId = :id. So it favors adding a JOIN and comparing the primary key column instead of comparing the foreign key column directly. That extra JOIN sometimes caused slow query plans in the DB.

So it is mainly used as a workaround for other issues.

[rbygrave]

Pushed a fix, again noting that really people shouldn’t need to map the same column twice.