Module com.darkcollective.relix.optimizer
Package com.darkcollective.relix.optimizer.internal

Class JoinSides

java.lang.Object
com.darkcollective.relix.optimizer.internal.JoinSides
public final class JoinSides extends Object
Which input of a binary join owns an attribute reference.

Deciding this by bare column name alone is not enough for the rules that need it: an equi-join's two sides usually share the joined column's name, so the qualifier is the only thing distinguishing A.x from B.x. A qualified reference is therefore resolved by column provenance — the same rule ArrayRow#get(String) applies at execution time — and only an unqualified one falls back to name exclusivity.

A dotted name that is a path into a nested column (location.city) is resolved by its head, which is the column it actually names — the reading Schema#resolvePath supplies, tried after the relation-qualified one and before the bare-name fallback.

Anything either input could answer is JoinSides.Side.UNKNOWN, never a guess: both callers (TransitiveEqualityPass deriving a filter for one side, OuterJoinDemotionPass asking whether a predicate constrains the null-supplying side) turn an unknown into a skipped rewrite, which costs an optimization and never an answer.