apache/shardingsphere · error · SQLParsingException

42000

42000

Error message

You have an error in your SQL syntax: %s

What it means

Thrown by SQLStatementVisitorFactory's default switch case when a SQLStatementType does not map to any visitor category (DML/DDL/TCL/LCL/DCL/DAL). Instead of a SQL syntax message, the payload is just the type name (e.g. 'DQL'), which is a known quirk: the message format string 'You have an error in your SQL syntax: %s' is filled with the type name, not the SQL. It signals an internal routing gap between the parsed statement's category and the available visitor facades.

Source

Thrown at parser/sql/engine/core/src/main/java/org/apache/shardingsphere/sql/parser/engine/core/database/visitor/SQLStatementVisitorFactory.java:64

    }
    
    @SneakyThrows(ReflectiveOperationException.class)
    private static SQLStatementVisitor createParseTreeVisitor(final DatabaseType databaseType, final SQLStatementVisitorFacade visitorFacade, final SQLStatementType type) {
        switch (type) {
            case DML:
                return visitorFacade.getDMLVisitorClass().getConstructor(DatabaseType.class).newInstance(databaseType);
            case DDL:
                return visitorFacade.getDDLVisitorClass().getConstructor(DatabaseType.class).newInstance(databaseType);
            case TCL:
                return visitorFacade.getTCLVisitorClass().getConstructor(DatabaseType.class).newInstance(databaseType);
            case LCL:
                return visitorFacade.getLCLVisitorClass().getConstructor(DatabaseType.class).newInstance(databaseType);
            case DCL:
                return visitorFacade.getDCLVisitorClass().getConstructor(DatabaseType.class).newInstance(databaseType);
            case DAL:
                return visitorFacade.getDALVisitorClass().getConstructor(DatabaseType.class).newInstance(databaseType);
            default:
                throw new SQLParsingException(type.name());
        }
    }
}

View on GitHub (pinned to e952770a21)

Solutions

1. Align versions of all shardingsphere parser modules (sql-parser-engine, dialect visitors) so categories and factory cases match
2. Upgrade to a release where the statement type's visitor branch exists
3. Avoid the unsupported statement category or rewrite the SQL into a supported one (e.g. DQL-select is DML in this model)
4. If extending ShardingSphere, add the visitor facade mapping for the new type

// Assert module version alignment before relying on visitor routing
String engineVersion = SQLParserExecutor.class.getPackage().getImplementationVersion();
String visitorVersion = SQLStatementVisitorFactory.class.getPackage().getImplementationVersion();
if (engineVersion != null && !engineVersion.equals(visitorVersion)) throw new IllegalStateException("Mixed parser module versions");

try { SQLStatementVisitorFactory.newInstance(...); } catch (SQLParsingException e) { throw new IllegalStateException("Parser/visitor version mismatch — align ShardingSphere modules", e); }

When it happens

Trigger: Parsing a statement whose visitor-required SQLStatementType falls outside the six handled cases — for example a type introduced by a new grammar or an unclassified statement — so newInstance switches hit default. Can also happen if a dialect visitor facade JAR is missing, though usually the failure then occurs earlier at SPI load.

Common situations: New statement categories added in newer ShardingSphere grammars but not yet handled by the factory in the running version; mixed-version jars on the classpath (parser engine newer than visitor modules); custom or experimental dialect extensions.

Related errors

• Unsupported format type %s
• This SPI implementation does not support the use of this met
• SPI:1
• SPI:1
• Build data consistency checker is not supported.

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