fix: EXPOSED-447 Eager loading does not work with composite PK entity

[bog-walk]

Description

Summary of the change:
It is now possible to use eager loading with references involving CompositeIdTable.

Detailed description:

• Why:
  Initial implementation of CompositeIdTable was already very large, so the necessary logic to use .load() and .with() was not included. preloadRelations() also relied heavily on inList, which was not capable of accepting an unknown-sized list of columns on the left hand side: PR feat: EXPOSED-446 Support N-column inList equality comparisons #2157

• How:

  • Add inList overloads for List<CompositeID> and for deconstructed CompositeIdTable.id
    • Unit test commented out due to SQL Server bug: PR chore: [SQL Server] Fix MultipleInListOp logic when isInList = false #2176
  • Refactor preloadRelations() to handle CompositeIdTable references (both parent and child)
  • Add variant to warmupReferences() that can work with multiple-column ids.

---

Type of Change

Please mark the relevant options with an "X":

• Bug fix

Affected databases:

• All

Checklist

• Unit tests are in place
• The build is green (including the Detekt check)
• All public methods affected by my PR has up to date API docs

---

Related Issues

EXPOSED-447

[bog-walk]

This test seems to be quite slow, I'm assuming because of the inTopLevelTransaction. I will split it locally into multiple tests and compare.

[e5l]

Could you use @ignore and log an issue instead of the comment?

[obabichevjb]

Minor: I expect that it's just extra check, but is it possible that non-EntityId column (actually here is Comparable, but I expect that it's always columns) has EntityIDColumnType, does it make sense?

By the way removing of it !is EntityID<*> || does not break tests (at least fo H2 and Postgres)

[bog-walk]

You're right. The tests were failing before (for case with double-wrapped EntityID<EntityID>) but not anymore, so I must have changed something in the logic lower down (hopefully it's not the tests that changed).

[obabichevjb]

Idea says that there are no usages of that function.

Actually, if I comment this function, and the one above (infix fun List<Column<*>>.notInList(list: Iterable<CompositeID>): InListOrNotInListBaseOp<List<*>>) I get tests green (at least for H2 and Postgres), is it just a lack of tests yet?

[bog-walk]

They are being tested in the test that was originally commented out before PR #2176 was merged.

[obabichevjb]

Probably better to name warmUpCompositeIdReferences

I read this code first time, and I haven't expected that additionally to the method warmUpAllReferences there is another one warmUpReferences. That's definitely minor.

[obabichevjb]

It's always used with one argument, so it could be split into 2 independen functions.

[obabichevjb]

Also minor, but negatives in arguments a bit harder to read, usually better to name without them (isCompositeIdReference in this case)

[obabichevjb]

I feel like it would be good idea to add a function to build CompositeID. This piece of code I was able to extract to

private fun compositeId(entries: List<Pair<Column<EntityID<Comparable<Any>>>, Comparable<Any>>>) = CompositeID {
    entries.forEachIndexed { i, entry ->
        it[entry.first] = entry.second
    }
}

so the call of it looks like

compositeId(refColumns.values.zip(childValues) as List<Pair<Column<EntityID<Comparable<Any>>>, Comparable<Any>>>)

Typing unfortunately looks already not a human readable a bit =)