You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@shardingsphere.apache.org by "alexalves83 (via GitHub)" <gi...@apache.org> on 2026/07/20 20:02:53 UTC

[I] Doris DDL compatibility issue in ShardingSphere Proxy 5.5.3 [shardingsphere]

alexalves83 opened a new issue, #39196:
URL: https://github.com/apache/shardingsphere/issues/39196

   #Doris DDL compatibility issue in ShardingSphere Proxy 5.5.3
   
   #Environment
   ShardingSphere Proxy: 5.5.3
   Backend database: Apache Doris
   JDBC Driver: mysql-connector-j-9.4.0
   
   #The proxy image contains Doris modules:
   shardingsphere-database-connector-doris-5.5.3.jar
   shardingsphere-parser-sql-engine-doris-5.5.3.jar
   shardingsphere-parser-sql-statement-doris-5.5.3.jar
   shardingsphere-proxy-dialect-doris-5.5.3.jar
   
   #Summary
   I successfully configured ShardingSphere Proxy 5.5.3 as a MySQL proxy in front of Apache Doris.
   The following operations work correctly:
   
   SHOW DATABASES;SHOW TABLES;DESCRIBE table_name;SHOW CREATE TABLE table_name;SELECT ...;INSERT ...;DELETE ...;
   The SQL is routed correctly to Doris.
   
   Example from the logs:
   Actual SQL: doris ::: SELECT * FROM TESTE_MEDIUMShow more lines
   Actual SQL: doris ::: INSERT INTO TESTE_MEDIUMVALUES (1000,'ALTERADO')Show more lines
   Actual SQL: doris ::: DELETEFROM TESTE_MEDIUMWHERE ID = 1000Show more lines
   
   Problem
   DDL statements containing Doris-specific syntax are rejected by the ShardingSphere parser before reaching the backend.
   
   Reproduction
   This statement is accepted and forwarded to Doris:
   SQLCREATE TABLE benchmark.TESTE1 (    ID_CONTRIBUINTE INT);
   
   Log:
   Actual SQL: doris ::: CREATE TABLE TESTE1 (    ID_CONTRIBUINTE INT)
   
   Doris responds:
   errCode = 2, detailMessage = replication num should be less than the number of available backends.
   This confirms that the statement reaches Doris.
   
   However, the following Doris DDL does not work:
   SQLCREATE TABLE benchmark.TESTE1 (    ID_CONTRIBUINTE INT)PROPERTIES (    "replication_num" = "1");
   
   Error:
   Plain TextERROR 1064 (42000): You have an error in your SQL syntax:no viable alternative at input 'PROPERTIES'
   
   Stack trace:
   Textorg.apache.shardingsphere.database.exception.core.exception.syntax.sql.DialectSQLParsingExceptionorg.apache.shardingsphere.infra.parser.ShardingSphereSQLParserEngine.parse(...)
   The statement is rejected during parsing and is never sent to Doris.
   
   Another example:
   CREATE TABLE benchmark.IFTD_CONTRIBUINTE (    ID_CONTRIBUINTE INT)DUPLICATE KEY(ID_CONTRIBUINTE)DISTRIBUTED BY HASH(ID_CONTRIBUINTE) BUCKETS 1PROPERTIES (    "replication_num" = "1");
   
   Error:
   ERROR 1064 (42000): You have an error in your SQL syntax:no viable alternative at input 'DUPLICATE'
   Additional Observation
   The parser also rejects:
   
   Example:
   SQLCREATE TABLE TEST (    ID MEDIUMINT);
   Result:
   no viable alternative at input 'MEDIUMINT'
   
   #Expected Behavior
   Since ShardingSphere Proxy 5.5.3 includes Doris-specific modules:
   Plain Textshardingsphere-database-connector-dorisshardingsphere-parser-sql-engine-dorisshardingsphere-parser-sql-statement-dorisshardingsphere-proxy-dialect-dorisShow more lines
   and the release notes mention improved Doris SQL compatibility, I expected Doris DDL syntax such as:
   SQLDUPLICATE KEYDISTRIBUTED BY HASHPROPERTIESMEDIUMINTShow more lines
   to be accepted and forwarded to the Doris backend.
   
   #Actual Behavior
   The Doris-specific DDL syntax is rejected by the parser:
   Plain TextDialectSQLParsingExceptionShow more lines
   before reaching the backend database.
   Can you confirm whether this is:
   
   A bug in the Doris parser implementation?
   A missing configuration?
   A currently unsupported subset of Doris DDL syntax?
   
   Thank you.


-- 
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: notifications-unsubscribe@shardingsphere.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [I] Doris DDL compatibility issue in ShardingSphere Proxy 5.5.3 [shardingsphere]

Posted by "terrymanu (via GitHub)" <gi...@apache.org>.
terrymanu closed issue #39196: Doris DDL compatibility issue in ShardingSphere Proxy 5.5.3
URL: https://github.com/apache/shardingsphere/issues/39196


-- 
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: notifications-unsubscribe@shardingsphere.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [I] Doris DDL compatibility issue in ShardingSphere Proxy 5.5.3 [shardingsphere]

Posted by "terrymanu (via GitHub)" <gi...@apache.org>.
terrymanu commented on issue #39196:
URL: https://github.com/apache/shardingsphere/issues/39196#issuecomment-5058185844

   Hi @alexalves83, thanks for the detailed report. This is a duplicate of #36081 and is a known database-type/dialect-selection bug, rather than a missing Doris grammar rule for the reported `DUPLICATE KEY`, `DISTRIBUTED BY HASH`, and `PROPERTIES` clauses.
   
   ShardingSphere 5.5.3 already includes those clauses in its Doris grammar and has a Doris parser integration case covering their combined use. The failure occurs earlier in dialect selection: Doris and MySQL both use the `jdbc:mysql:` URL prefix, and when both dialect modules are present, ShardingSphere resolves the storage type to the trunk MySQL type. ShardingSphere-Proxy then parses statements using that resolved logical-database protocol type, so the Doris parser module is not selected. The [5.5.3 Doris documentation](https://shardingsphere.apache.org/document/5.5.3/en/user-manual/shardingsphere-jdbc/optional-plugins/doris-fe/) documents this exact limitation and links to #36081.
   
   PR #36090 attempted to address the selection behavior but was closed without merge, and #36081 remains open with `status: blocked`; there is no merged fix or fixed release to verify yet. Please follow #36081 for the eventual resolution. I suggest labeling this issue as `type: duplicate`, `db: Doris`, and `in: infra`, then closing it as a duplicate.
   
   The standalone `MEDIUMINT` observation does not fully match the same explanation because both the MySQL and Doris grammars in 5.5.3 accept `MEDIUMINT`. If that statement still fails independently, please provide its exact unabridged exception and the effective Proxy protocol/database configuration as a focused follow-up, because it may use a different parser-selection path.


-- 
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: notifications-unsubscribe@shardingsphere.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org