Actually, its even worse. The problem is the coordination done in TableBinder#bindForeignKey… Here we have implicit columns derived from the target entity (here its id), which triggers TableBinder#bindImplicitColumns. #bindImplicitColumns defines the columns properly - the order and definitions are perfect. The trouble starts with the next step which is a call to ToOne#createForeignKey - the very first thing it does it to try to “sort properties”, which is funny because a to-one has no properties to actually sort. But what it does is to attempt to sort the columns and set its “type index”. Based on the “original order” of the composite id. This goes off the rails in 2 ways
- it messes up the already proper column order
- it also messes up the “type index” references which is why we see strange type details on the key side
Simply skipping the sorting for implicit, non-aggregated keys leads to later problems however. Deep rabbit hole. |