I dunno man, pissing at the bottom of rabbit holes is perhaps not so advisable if we wanna stay dry down here….

Oh I missed the pissing contest! Do I still have time to make it?

As deep as the hole I’m down with enum mappings?

After #bindImplicitColumnswe have -

The columns for PersistentClass(B).getIdentifier().getColumns() -

1. Column(code)

2. Column(cost)

3. Column(id)

4. Column(type)

The columns for ToOne(A.b) -

1. Column(b_code)

2. Column(b_cost)

3. Column(b_id)

4. Column(b_type)

And as I mentioned, the type details are correct.

Actually, its even worse. The problem is the coordination done in TableBinder#bindForeignKey…

In this case, we have implicit columns derived from the target entity (specifically 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

1. it messes up the already proper column order

2. 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.