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.

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
Defensive patterns

Strategy: validation

Validate before calling

// 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 / catch

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

Prevention

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


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

Appendix: 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)