You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The FieldReference POJO includes a field to store its type, which is set based on the input rel when it is created.
When the plan tree is modified by the RelCopyOnWrite visitor, existing field refs are copied over as they are. This includes the stored type. If the visitation changes the output type of a relation, FieldReferences to changed columns are not updated.
Code Example
The test below illustrates this issue:
@TestvoidstaleFieldRefStateAfterCopyOnWriteVisitation() {
varb = newSubstraitBuilder(extensions);
TypeCreatorR = TypeCreator.of(false);
TypeCreatorN = TypeCreator.of(true);
varplan =
b.project(
input -> List.of(b.fieldReference(input, 0)),
// original named scan has type R.I64b.namedScan(List.of("example"), List.of("n"), List.of(R.I64)));
varnewPlanOption =
plan.accept(
newRelCopyOnWriteVisitor() {
@OverridepublicOptional<Rel> visit(NamedScannamedScan) throwsRuntimeException {
// replace the original named scan with one of type N.I64returnOptional.of(b.namedScan(List.of("example"), List.of("n"), List.of(N.I64)));
}
});
// decompose the new planassertTrue(newPlanOption.isPresent());
varnewPlan = newPlanOption.get();
assertInstanceOf(Project.class, newPlan);
varnewProject = (Project) newPlan;
assertInstanceOf(NamedScan.class, newProject.getInput());
varnewNamedScan = (NamedScan) newProject.getInput();
// the new named scan emits single column of type N.I64, as expectedassertEquals(NamedStruct.of(List.of("n"), R.struct(N.I64)), newNamedScan.getInitialSchema());
// retrieve the field referencevarexprs = newProject.getExpressions();
assertTrue(exprs.size() == 1);
varexpr = exprs.get(0);
assertInstanceOf(FieldReference.class, expr);
varfieldRef = (FieldReference) expr;
// The field reference type should correspond to the type of the new named scan.// Instead, the type is R.I64 which is from the ORIGINAL named scanassertEquals(fieldRef.type(), N.I64); // <- FAILS
}
Fixing
In the short-term, it's enough to update the RelCopyOnWrite visitor to update FieldReferences as necessary.
However, we should consider whether we should be caching these types at all. It might make sense to force type derivation of expressions to take place relative to the input relation of the expression. That is to say, we can only determine the type of a FieldReference when we now the input relation to the FieldReference.
The text was updated successfully, but these errors were encountered:
The FieldReference POJO includes a field to store its type, which is set based on the input rel when it is created.
When the plan tree is modified by the RelCopyOnWrite visitor, existing field refs are copied over as they are. This includes the stored type. If the visitation changes the output type of a relation, FieldReferences to changed columns are not updated.
Code Example
The test below illustrates this issue:
Fixing
In the short-term, it's enough to update the RelCopyOnWrite visitor to update FieldReferences as necessary.
However, we should consider whether we should be caching these types at all. It might make sense to force type derivation of expressions to take place relative to the input relation of the expression. That is to say, we can only determine the type of a FieldReference when we now the input relation to the FieldReference.
The text was updated successfully, but these errors were encountered: