-
Notifications
You must be signed in to change notification settings - Fork 13.5k
[FLINK-37789][3/N] introduce ml builtin sql functions and sql validator changes #26553
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
42fcaec
to
64363a9
Compare
@lihaosky could we add unit tests please for the new methods please |
...src/main/java/org/apache/flink/table/planner/functions/sql/ml/SqlMlPredictTableFunction.java
Outdated
Show resolved
Hide resolved
...src/main/java/org/apache/flink/table/planner/functions/sql/ml/SqlMlPredictTableFunction.java
Outdated
Show resolved
Hide resolved
d48945e
to
539ce03
Compare
18011a9
to
5aa3803
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your contribution. I left some comments
...src/main/java/org/apache/flink/table/planner/functions/sql/ml/SqlMlPredictTableFunction.java
Outdated
Show resolved
Hide resolved
...lanner/src/main/java/org/apache/flink/table/planner/functions/sql/ml/SqlMlTableFunction.java
Outdated
Show resolved
Hide resolved
...lanner/src/main/java/org/apache/flink/table/planner/functions/sql/ml/SqlMlTableFunction.java
Outdated
Show resolved
Hide resolved
...lanner/src/main/java/org/apache/flink/table/planner/functions/sql/ml/SqlMlTableFunction.java
Outdated
Show resolved
Hide resolved
flink-table/flink-table-planner/src/main/java/org/apache/calcite/sql/SqlModelCall.java
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your update.
@@ -2573,7 +2575,7 @@ private SqlNode registerFrom( | |||
if (operand instanceof SqlBasicCall) { | |||
final SqlBasicCall call1 = (SqlBasicCall) operand; | |||
final SqlOperator op = call1.getOperator(); | |||
if (op instanceof SqlWindowTableFunction | |||
if ((op instanceof SqlWindowTableFunction || op instanceof SqlMLTableFunction) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am confuesd about the change and I can not produce a case have the same error as SqlWindowFunction. I am not sure FLINK-35619 is a good solution here, which tries to validate a node when validating namespace. However, in most cases, validator should register the namespace for the node and then validate.
private SqlNode validateScopedExpression(SqlNode topNode, SqlValidatorScope scope) {
SqlNode outermostNode = performUnconditionalRewrites(topNode, false);
cursorSet.add(outermostNode);
top = outermostNode;
TRACER.trace("After unconditional rewrite: {}", outermostNode);
if (outermostNode.isA(SqlKind.TOP_LEVEL)) {
// 1. REGISTER namespace
registerQuery(scope, null, outermostNode, outermostNode, null, false);
}
// 2. VALIDATE node
outermostNode.validate(this, scope);
if (!outermostNode.isA(SqlKind.TOP_LEVEL)) {
// force type derivation so that we can provide it to the
// caller later without needing the scope
deriveType(scope, outermostNode);
}
TRACER.trace("After validation: {}", outermostNode);
return outermostNode;
}
How about removing the change here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah. This one doesn't seem to have effect. The first select scope should be used when validating descriptor's operands. I made changes there
if (node instanceof SqlExplicitModelCall) { | ||
// Convert it so that model can be accessed in planner. SqlExplicitModelCall | ||
// from parser can't access model. | ||
SqlExplicitModelCall modelCall = (SqlExplicitModelCall) node; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about we only rewrite the call if the model is not null here. For example, SqlValidatorImpl#performUnconditionalRewrites
override the operator if the function is found.
if (call.getOperator() instanceof SqlUnresolvedFunction) {
assert call instanceof SqlBasicCall;
final SqlUnresolvedFunction function = (SqlUnresolvedFunction) call.getOperator();
// This function hasn't been resolved yet. Perform
// a half-hearted resolution now in case it's a
// builtin function requiring special casing. If it's
// not, we'll handle it later during overload resolution.
final List<SqlOperator> overloads = new ArrayList<>();
opTab.lookupOperatorOverloads(
function.getNameAsId(),
function.getFunctionType(),
SqlSyntax.FUNCTION,
overloads,
catalogReader.nameMatcher());
if (overloads.size() == 1) {
((SqlBasicCall) call).setOperator(overloads.get(0));
}
}
I think we can have the same logic here
if (node instanceof SqlExplicitModelCall) {
// Convert it so that model can be accessed in planner. SqlExplicitModelCall
// from parser can't access model.
FlinkCalciteCatalogReader catalogReader =
(FlinkCalciteCatalogReader) getCatalogReader();
CatalogSchemaModel model = catalogReader.getModel(((SqlExplicitModelCall) node).getIdentifier());
if (model != null) {
return new SqlModelCall(model);
}
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Getting model here should be fine. But SqlExplicitModelCall
with model identifier expects the model to exist so we should enforce that here. If there are cases where model doesn't need to exist in other cases, we can revisit?
What is the purpose of the change
Add Builtin
SqlTableFunction
forml_predict
and make sql validator passBrief change log
SqlMlTableFunction
andSqlMlPredictTableFunction
Verifying this change
Skeleton. Will add test in following up PRs during integration
Does this pull request potentially affect one of the following parts:
@Public(Evolving)
: (no)Documentation