java.lang.Object
com.darkcollective.relix.symbol.internal.NestedPaths

public final class NestedPaths extends Object
Which of a join's two inputs a dotted reference reaches into.

A dotted name is ambiguous by construction: location.city is either a qualified reference to a relation's column or a path into a nested one, and only the headings can say which. Resolving it by its tail binds it to whichever side happens to carry a column called city, which is how a predicate over the left input came to be evaluated against the right — as a selection pushed into the wrong relation, and at run time as a comparison of the right's value with itself, so the join matched every pair and quietly became a cross product.

An open schema owns nothing here. Schema-on-read resolves every name, so its answer to "do you carry this path" is vacuously yes and carries no evidence. That is the part worth having in one place: it has been gotten wrong independently in the optimizer and in the executor, and in both the mistake was the same one — guarding the whole comparison on both sides being closed, rather than declining the open side's answer. Those are not the same thing, because what follows a declined comparison is a fall back to the bare tail, which an open schema also answers.

Note what this deliberately does not change: asking one open schema to resolve a path is right, and inference depends on it. An open source really can carry location.city, and it types as ANY. What is worthless is that same answer used as evidence against another side.

Since:
0.1
  • Method Details

    • ownerOf

      public static NestedPaths.Owner ownerOf(String reference, Schema left, Schema right)
      Returns which input resolves reference as a path into a nested column.
      Parameters:
      reference - the dotted reference, as written
      left - the left input's heading; never null
      right - the right input's heading; never null
      Returns:
      which input resolves reference as a path into a nested column