One of the invariants of Query.Or(lhs, rhs) is that the columns in
lhs should match the columns in rhs (really they should be in the
same order, but the runtime's columns are unordered, so that point is a
little tenuous).
This invariant was violated in queries like the one added in tests. The
crux is that the implied MATCH in the MERGE may bind additional
variables that aren't needed or bound for the implied CREATE. This
means that sometimes you end up with an Or(matchQuery, createQuery)
where the matchQuery has extra columns not in the createQuery.
The fix is straightforward: since the variables bound in the CREATE
are always a subset of those bound in the MATCH, we can adjust the
MATCH side of the query to keep only the same variables coming out of
the CREATE side.
emanb29
commented
1 year ago
One of the invariants of
Query.Or(lhs, rhs)is that the columns inlhsshould match the columns inrhs(really they should be in the same order, but the runtime's columns are unordered, so that point is a little tenuous).This invariant was violated in queries like the one added in tests. The crux is that the implied
MATCHin theMERGEmay bind additional variables that aren't needed or bound for the impliedCREATE. This means that sometimes you end up with anOr(matchQuery, createQuery)where thematchQueryhas extra columns not in thecreateQuery.The fix is straightforward: since the variables bound in the
CREATEare always a subset of those bound in theMATCH, we can adjust theMATCHside of the query to keep only the same variables coming out of theCREATEside.