A few contracts used during SQL AST creation define overloaded methods where one form accepts a {{SqlAstCreationState}} and is defined as {{default}} calling another form with values extracted from {{SqlAstCreationState}}. E.g.
{noformat}public interface TableGroupJoinProducer ... {
default TableGroupJoin createTableGroupJoin(
NavigablePath navigablePath,
TableGroup lhs,
String explicitSourceAlias,
SqlAstJoinType sqlAstJoinType,
boolean fetched,
boolean addsPredicate,
SqlAstCreationState creationState) {
return createTableGroupJoin(
navigablePath,
lhs,
explicitSourceAlias,
sqlAstJoinType,
fetched,
addsPredicate,
creationState.getSqlAliasBaseGenerator(),
creationState.getSqlExpressionResolver(),
creationState.getFromClauseAccess(),
creationState.getCreationContext()
);
}
TableGroupJoin createTableGroupJoin(
NavigablePath navigablePath,
TableGroup lhs,
String explicitSourceAlias,
SqlAstJoinType sqlAstJoinType,
boolean fetched,
boolean addsPredicate,
SqlAliasBaseGenerator aliasBaseGenerator,
SqlExpressionResolver sqlExpressionResolver,
FromClauseAccess fromClauseAccess,
SqlAstCreationContext creationContext);
}{noformat}
The problem is that in a few cases we actually need the {{SqlAstCreationState}} reference within the handling of these calls. A really bad habit I have seen in the code in these cases is to simply pass {{null}} for the {{SqlAstCreationState}} 😞
The “proper” fix would be to address this everywhere to always pass along the {{SqlAstCreationState}}, however that is likely to have a big impact. While all of the affected contracts are incubating we should still try to minimize changes. |
|
