github-actions[bot] commented on code in PR #66708:
URL: https://github.com/apache/doris/pull/66708#discussion_r3780679521
##########
fe/fe-connector/fe-connector-jdbc/src/main/java/org/apache/doris/connector/jdbc/JdbcDorisConnector.java:
##########
@@ -295,6 +299,10 @@ private String resolveDriverUrl(String driverUrl) {
if (driverUrl == null || driverUrl.isEmpty()) {
return driverUrl;
}
+ String materializedUrl = context.resolveJdbcDriverUrl(driverUrl,
props.getDriverChecksum());
Review Comment:
[P1] Preserve connector-side driver resolution before materializing. The
production hook never returns null and resolves only through
`Config.jdbc_drivers_dir`, so this call makes the
`JdbcConf.driversDir(context)` fallback below unreachable. Catalogs using
plugin `jdbc.conf` directories now fail, and replayed absolute driver paths are
rejected before the unchanged compatibility branch. Resolve the effective
connector source first (or pass it into materialization), and cover both
real-context replay cases.
##########
fe/fe-connector/fe-connector-spi/src/main/java/org/apache/doris/connector/spi/ConnectorContext.java:
##########
@@ -52,6 +52,19 @@ default Map<String, String> getEnvironment() {
return Collections.emptyMap();
}
+ /**
+ * Resolves and materializes a JDBC driver through engine-owned storage
services.
+ *
+ * <p>The checksum identifies immutable driver content. An engine
implementation may return a
+ * checksum-versioned local URL so lazy connector creation after replay or
FE promotion does not
+ * depend on a file left by the FE that originally created the catalog.
The default returns
+ * {@code null}; standalone connector tests and engines without this
service retain the connector's
+ * local directory resolution.
+ */
+ default String resolveJdbcDriverUrl(String driverUrl, String checksum) {
Review Comment:
[P1] Bump the connector plugin API for this new SPI method.
`ConnectorContext` is frozen by `ConnectorPluginSurfaceTest`, but the recorded
surface lacks this method while the API and pinned assertion remain 5.0. A JDBC
plugin built here is therefore admitted by an older 5.0 FE and then links this
call against the parent-first old SPI, failing with `NoSuchMethodError`.
Refresh the surface, bump the API to the next major, and cover
old-FE/new-plugin rejection.
##########
fe/fe-core/src/main/java/org/apache/doris/catalog/JdbcResource.java:
##########
@@ -441,7 +530,21 @@ private static String
checkAndReturnDefaultDriverUrl(String driverUrl) {
File targetFile = new File(targetPath);
String oldTargetPath = defaultOldDriverUrl + "/" + driverUrl;
File oldTargetFile = new File(oldTargetPath);
- if (targetFile.exists()) {
+ if (CloudPluginDownloader.isLegacySaaSMode()) {
+ // The instance object store is authoritative in legacy SaaS
mode. Always publish
+ // its current contents atomically instead of trusting a stale
file from an earlier
+ // catalog creation.
+ try {
+ String downloadedPath =
CloudPluginDownloader.downloadFromCloud(
Review Comment:
[P2] Avoid downloading the driver twice during CREATE. Validation first
resolves the driver and then computes its checksum, and both operations
independently enter this branch, so one legacy-SaaS CREATE performs two serial
MetaService RPCs and full jar copies; the first resolved URL is discarded even
with `test_connection=false`. Materialize once and compute the checksum from
that result (or return both from one operation).
--
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
