Admaing opened a new pull request, #255: URL: https://github.com/apache/flink-connector-jdbc/pull/255
## What is the purpose of the change Fixes [FLINK-41051](https://issues.apache.org/jira/browse/FLINK-41051). `JdbcSource.getLineageVertex()` and `JdbcRowDataLookupFunction.getLineageVertex()` derived the lineage dataset name by parsing SQL with OpenLineage's parser, while since FLINK-40743 the Table sink reports the configured `table-name`. Deriving the name from SQL at plan time is the wrong source of truth: the planner reads lineage before the source connects, so the parser has to be loaded during planning (native library, planner classloader), and it can only recover a name that happens to be parseable inside the generated query — for a name that a database requires quoting for it returns an empty or wrong name. Both the Table source and the lookup function already know the configured `table-name`, so they now report it directly, exactly like the sink does. A DataStream `JdbcSource` built from a query keeps the parser, because the query is all it has. ## Brief change log - `JdbcSourceBuilder` gains an optional, nullable `setLineageTableName(String)`; `JdbcSource` reports it in `getLineageVertex()` when set and falls back to `LineageUtils.tableNameOf(splitterEnumerator.lineageQueries(), true)` when unset, so the DataStream path is unchanged. The new setter is additive on a `@PublicEvolving` class. - `JdbcDynamicTableSource#getScanRuntimeProvider()` passes `options.getTableName()` to the source builder. - `JdbcRowDataLookupFunction` stores `options.getTableName()` in a field and reports it in `getLineageVertex()` instead of parsing the generated lookup query. - `JdbcRowDataInputFormat` is untouched. ## Verifying this change New plan-time tests (they read the lineage vertex before `open()`/before the job runs, like `JdbcDynamicTableSinkITCase#testLineageDatasetNameIsKnownAtPlanTime`): - `JdbcDynamicTableSourceITCase#testScanLineageDatasetNameIsKnownAtPlanTime` — Table scan source reports the configured `table-name` at plan time (lineage graph of the source transformation). - `JdbcDynamicTableSourceITCase#testScanLineageDatasetNameIsNotParsedFromTheQuery` — same for a table name the SQL parser cannot recover from the generated query. - `JdbcRowDataLookupFunctionTest#testLineageDatasetNameIsKnownAtPlanTime` and `#testLineageDatasetNameIsNotParsedFromTheQuery` — the lookup function reports the configured table name without being opened. - The DataStream path (a `JdbcSource` built from a query still uses the parser) stays covered by the existing `JdbcSourceITCase#testGetLineageVertex`, which still passes unchanged. Red-green: with the production changes reverted and the new tests unchanged, the two `...IsNotParsedFromTheQuery` tests fail with `expected: "jdbc-lineage-source" but was: ""` and `expected: "lookup-table" but was: ""`. The two `...IsKnownAtPlanTime` tests pass before the change as well, because the parser round-trips a plain `SELECT ... FROM t` query to the same name; they pin the contract for ordinary table names, the other two pin independence from the parser. Commands (Java 17): ``` ./mvnw -pl flink-connector-jdbc-core -am -Dtest='JdbcRowDataLookupFunctionTest,DerbyDynamicTableSourceITCase,JdbcSourceITCase' \ -Dsurefire.failIfNoSpecifiedTests=false -Dspotless.check.skip=true -Dcheckstyle.skip=true -Drat.skip=true test # Tests run: 39, Failures: 0, Errors: 0, Skipped: 0 ./mvnw -pl flink-connector-jdbc-core -am test # Tests run: 253, Failures: 0, Errors: 0, Skipped: 1 ./mvnw -pl flink-connector-jdbc-core -am integration-test # integration tests (Derby/H2 only, no Docker) ./mvnw -pl flink-connector-jdbc-core spotless:check checkstyle:check # 0 Checkstyle violations, Spotless clean ``` ## Does this pull request potentially affect one of the following parts: - Dependencies (does it add or upgrade a dependency): no - The public API, i.e., is any changed class annotated with `@Public(Evolving)`: yes — one additive setter, `JdbcSourceBuilder#setLineageTableName(String)`; no existing signature changes - The serializers: no - The runtime per-record code paths (performance sensitive): no - Anything that affects deployment or recovery: no - The S3 file system connector: no ## Documentation - Does this pull request introduce a new feature? no (user-visible behaviour fix) - If yes, how is the feature documented? JavaDocs on the new setter and on the nullable `JdbcSource` field --- ##### Was generative AI tooling used to co-author this PR? - [X] Yes (please specify the tool below) Generated-by: DeepSeek Harness (deepseek-v4.1-flash) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
