apache/shardingsphere · error · UnsupportedSQLOperationException

Unsupported data source type `%s`

Error message

Unsupported data source type `%s`

What it means

PipelineDataSourceConfigurationFactory.newInstance(type, param) is a string-keyed factory supporting only StandardPipelineDataSourceConfiguration.TYPE and ShardingSpherePipelineDataSourceConfiguration.TYPE. Any other type string falls through the switch to UnsupportedSQLOperationException('Unsupported data source type `type`'). It is typically invoked when parsing the dataSourceConfig of a migration/scaling job.

Source

Thrown at kernel/data-pipeline/core/src/main/java/org/apache/shardingsphere/data/pipeline/core/datasource/config/PipelineDataSourceConfigurationFactory.java:48

@NoArgsConstructor(access = AccessLevel.PRIVATE)
public final class PipelineDataSourceConfigurationFactory {
    
    /**
     * Create new instance of pipeline data source configuration.
     *
     * @param type type of pipeline data source configuration
     * @param param parameter of pipeline data source configuration
     * @return created instance
     * @throws UnsupportedSQLOperationException unsupported SQL operation exception
     */
    public static PipelineDataSourceConfiguration newInstance(final String type, final String param) {
        switch (type) {
            case StandardPipelineDataSourceConfiguration.TYPE:
                return new StandardPipelineDataSourceConfiguration(param);
            case ShardingSpherePipelineDataSourceConfiguration.TYPE:
                return new ShardingSpherePipelineDataSourceConfiguration(param);
            default:
                throw new UnsupportedSQLOperationException(String.format("Unsupported data source type `%s`", type));
        }
    }
}

View on GitHub (pinned to e952770a21)

Solutions

  1. Use the exact factory-recognized type constants: the value of StandardPipelineDataSourceConfiguration.TYPE for plain JDBC URLs, or ShardingSpherePipelineDataSourceConfiguration.TYPE for proxied data sources.
  2. Inspect the constant values in your ShardingSphere version (they can change between releases) rather than relying on memory.
  3. Trim and validate the type string before job submission; treat anything outside the two constants as a configuration error.

Example fix

// before
PipelineDataSourceConfiguration cfg = PipelineDataSourceConfigurationFactory.newInstance("MySQL", url);

// after
PipelineDataSourceConfiguration cfg = PipelineDataSourceConfigurationFactory.newInstance(StandardPipelineDataSourceConfiguration.TYPE, url);
Defensive patterns

Strategy: validation

Validate before calling

Set<String> supported = Set.of(StandardPipelineDataSourceConfiguration.TYPE, ShardingSpherePipelineDataSourceConfiguration.TYPE);
if (!supported.contains(type)) {
    throw new IllegalArgumentException("dataSourceConfig type must be one of " + supported + ", got: " + type);
}

Try / catch

try {
    PipelineDataSourceConfiguration cfg = PipelineDataSourceConfigurationFactory.newInstance(type, param);
} catch (final UnsupportedSQLOperationException ex) {
    // fix the type field in the job's dataSourceConfig and resubmit
}

Prevention

When it happens

Trigger: Submitting a MIGGL/distsql job (or building a pipeline job config programmatically) whose dataSourceConfig type field is something like 'MySQL', 'Jdbc', 'sharding', or an empty/garbage string instead of one of the two supported TYPE constants.

Common situations: Hand-writing distsql MIGRATE DATABASE rules and guessing the type name; JSON/YAML key drift after a ShardingSphere upgrade renamed or consolidated types; frontend/UI emitting the wrong type tag; trailing whitespace or wrong case in the type string.

Related errors


AI-assisted analysis of apache/shardingsphere@e952770a21 (2026-08-14). Data as JSON: /api/errors/bab5df07362cfa34. Report an issue: GitHub.