SbloodyS commented on issue #18600: URL: https://github.com/apache/dolphinscheduler/issues/18600#issuecomment-5541253101
-1 from my side. I have concerns about the current proposal because it seems to assume that a datasource is essentially JDBC-based, while this is not true for the existing datasource ecosystem in DolphinScheduler. Besides JDBC-based datasource types, we already have (and may introduce more) datasource types whose connection model, parameters, metadata operations, and runtime behavior cannot be represented by a generic JDBC abstraction. For example, the proposed generic JDBC-style fallback form (host, port, user, password, database, JDBC parameters, etc.) only works for JDBC-compatible datasources. The same assumption also appears in several other parts of the proposal, including connectivity testing, metadata browsing, driver packaging, and task execution. This means that introducing a generic "custom datasource plugin" mechanism based primarily on the JDBC model may create significant compatibility and extensibility issues. We would likely need additional special cases later for every non-JDBC datasource type, which defeats the purpose of making the datasource framework truly pluggable. I think before changing the core datasource SPI, persistence model, frontend, and execution path, we should first define a datasource abstraction that can cover both JDBC and non-JDBC datasource types. -- 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]
