I have next hierarchy of classes/entities
In code above I've skipped all the setters, getters and constructors.
When I run application, hibernate creates tables with all required columns but doesn't create constraint for foreign key for next field in table UserTask.
Nevertheless constraint for the field "private Task task;" is being created successfully.
In the execution output I see
I use update hbm2ddl.auto property
Windows 10, MS SQL 2016
I added a fix now that should handle this special case where "only a single table" in the TABLE_PER_CLASS strategy exists.
Thanks for your reply.
>>To what table should it create a FK to?
I supposed that it should create FK to table RegularUser.
>>You entity User uses the TABLE_PER_CLASS strategy, so every subclass will have a different table
Right. And as I understand every subclass has its own private Long userId property inherited from base class and as result every table will have its own column UserID so why hibernate can't just use this property to create FK to it.
>>Do you have any other subclasses of User?
Yes, I do. I have several subclasses of abstract class User and more over, some of that subclasses also have subclasses.
To be more precise I have hierarchy like next
and so on.
The strange thing here for me is that I have two other classes with @JoinColumn annotation similar to hierarchy above and in that case all works fine.
These are those classes
Well in the code I tested it worked fine. I guess it makes a difference if you have further subtypes i.e. if Company had other subtypes, then the FK would not be generated. This is the case with your RegularUser apparently since it has subtypes Admins and Editors. Since instances of these subtypes do not have an entry in the table for RegularUser, Hibernate can't add a FK constraint from UserTask to RegularUser. That would be wrong. What you maybe want, is to have SINGLE_TABLE inheritance for subclasses of RegularUser, then there wouldn't be the tables Admins and Editors but a discriminator column would be introduced in the RegularUsers table to distinguish the subtypes. Unfortunately this is not yet possible. For further information see
Yes, now I see the reason. Thank you!
I agree with .
I'm going to reject this jira.