eye-gu opened a new issue, #18377:
URL: https://github.com/apache/dolphinscheduler/issues/18377

   ### Search before asking
   
   - [x] I had searched in the 
[issues](https://github.com/apache/dolphinscheduler/issues?q=is%3Aissue) and 
found no similar feature requirement.
   
   
   ### Description
   
   ## Background
   
   DolphinScheduler's datasource layer is already plugin-based via SPI. 
However, datasource plugins still cannot be extended by users with their own 
custom types. The root cause is that the DbType enum is hardwired into multiple 
layers of the type system, making it physically impossible for an external 
plugin to register a type that doesn't exist in the built-in enum.
   
   1. The DbType enum is hardcoded throughout the SPI and storage layers
   
   The DataSourceProcessor.getDbType() method returns DbType (a compile-time 
enum). An external plugin jar cannot return a DbType constant that doesn't 
exist in dolphinscheduler-spi, so it can only override existing types, never 
add new ones. 
   
   2. UI datasource type lists are hardcoded in the frontend
   
   The "create datasource" dialog and the task-node datasource selector both 
use hardcoded type arrays. Even if a custom plugin is deployed, its type never 
appears in the UI. The lists should be fetched from a backend API (e.g. GET 
/datasources/types) that returns all registered type names. For custom/unknown 
types, the generic JDBC form (host/port/user/password/database) is sufficient 
for the vast majority of cases.
   
   3. t_ds_datasource.type column needs to change from numeric code to string 
name
   
   Currently tinyint storing the enum's integer code. It should become varchar 
storing the type name string (e.g. "MYSQL"). A migration is needed to translate 
existing integer codes to name strings.The task definition / task instance 
tables already store the datasource type as a string name inside the 
task_params JSON (e.g. "type":"MYSQL"), so no change is needed there.
   
   ## Proposed Solution
   
   Relax DbType to a built-in constant collection (keep the enum, remove the 
integer code). Change all type-lookup and storage paths to use String type 
names — aligned with the existing task plugin design (TaskDefinition.taskType 
is already String).
   Add a GET /datasources/types endpoint returning all registered type names. 
Frontend fetches this for both the datasource dialog and task-node dropdowns, 
falling back to a generic JDBC form for non-builtin types.
   Change t_ds_datasource.type to varchar(64)
   
   ### Are you willing to submit a PR?
   
   - [x] Yes I am willing to submit a PR!
   
   ### Code of Conduct
   
   - [x] I agree to follow this project's [Code of 
Conduct](https://www.apache.org/foundation/policies/conduct)
   


-- 
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]

Reply via email to