Issue 1:
Bug Report

For English only, other languages will not accept.

Before report a bug, make sure you have:

Searched open and closed GitHub issues.

Read documentation: ShardingSphere Doc.

Please pay attention on issues you submitted, because we maybe need more details.

If no response more than 7 days and we cannot reproduce it on current information, we will close it.

Please answer these questions before submitting your issue. Thanks!

Which version of ShardingSphere did you use?

4.0.0-RC2

Which project did you use? Sharding-JDBC or Sharding-Proxy?

Sharding-JDBC

Expected behavior

Successfully read from tables with columns of clob types ( with @lob annotation).

Actual behavior

Got the following error:

org.springframework.dao.InvalidDataAccessApiUsageException: java.lang.String cannot be cast to java.sql.Clob; nested exception is java.lang.IllegalArgumentException: java.lang.String cannot be cast to java.sql.Clob

The same code works for original DataSource from springboot.

Reason analyze (If you can)

Steps to reproduce the behavior, such as: SQL to execute, sharding rule configuration, when exception occur etc.

Example codes for reproduce this issue (such as a github link).

Issue 2:
Bug Report

For English only, other languages will not accept.

Before report a bug, make sure you have:

Searched open and closed GitHub issues.

Read documentation: ShardingSphere Doc.

Please pay attention on issues you submitted, because we maybe need more details.

If no response anymore and we cannot reproduce it on current information, we will close it.

Please answer these questions before submitting your issue. Thanks!

Which version of ShardingSphere did you use?

5.0.0-RC1(From https://dist.apache.org/repos/dist/dev/shardingsphere/5.0.0-RC1/ , not master branch)

Which project did you use? ShardingSphere-JDBC or ShardingSphere-Proxy?

ShardingSphere-Proxy

Expected behavior

When I click on the library table in the SQLyog GUI to operate normally, the Proxy terminal should not have an error level log.

The following is my operation log in SQLyog.

/*[22-Oct 13:20:02][17 ms]*/ SHOW VARIABLES LIKE 'AUTOCOMMIT';
/*[22-Oct 13:20:02][2 ms]*/ SHOW DATABASES;
/*[22-Oct 13:20:04][1 ms]*/ USE `sharding_db`;
/*[22-Oct 13:20:05][2 ms]*/ SHOW FULL TABLES FROM `sharding_db` WHERE table_type = 'BASE TABLE';
/*[22-Oct 13:20:06][30 ms]*/ DESCRIBE `sharding_db`.`tb_result3_sharding_sphere`;
/*[22-Oct 13:20:06][19 ms]*/ SHOW INDEX FROM `sharding_db`.`tb_result3_sharding_sphere`;
/*[22-Oct 13:21:21][39789 ms]*/ SELECT * FROM `sharding_db`.`tb_result3_sharding_sphere` LIMIT 0, 1000;
/*[22-Oct 13:21:21][12 ms]*/ SHOW CREATE TABLE `sharding_db`.`tb_result3_sharding_sphere`;
/*[22-Oct 13:21:21][27 ms]*/ SHOW FULL FIELDS FROM `sharding_db`.`tb_result3_sharding_sphere`;
/*[22-Oct 13:21:21][11 ms]*/ SHOW KEYS FROM `sharding_db`.`tb_result3_sharding_sphere`;

Actual behavior

Of course, everything is normal in SQLyog, and the select statement is executed normally. I have not seen any abnormalities in SQLyog, but I found error level logs on the terminal of ShardingSphere-Proxy, which puzzled me.

[INFO ] 2021-10-22 13:18:32.839 [main] o.a.s.p.frontend.ShardingSphereProxy - ShardingSphere-Proxy start success
[ERROR] 2021-10-22 13:19:47.669 [Connection-5-ThreadExecutor] o.a.s.p.f.c.CommandExecutorTask - Exception occur:
java.lang.UnsupportedOperationException: unsupported table : `EVENTS`
at org.apache.shardingsphere.proxy.backend.text.admin.mysql.MySQLInformationSchemaExecutorFactory.newInstance(MySQLInformationSchemaExecutorFactory.java:52)
at org.apache.shardingsphere.proxy.backend.text.admin.mysql.MySQLAdminExecutorFactory.newInstance(MySQLAdminExecutorFactory.java:95)
at org.apache.shardingsphere.proxy.backend.text.admin.DatabaseAdminBackendHandlerFactory.newInstance(DatabaseAdminBackendHandlerFactory.java:78)
at org.apache.shardingsphere.proxy.backend.text.TextProtocolBackendHandlerFactory.newInstance(TextProtocolBackendHandlerFactory.java:86)
at org.apache.shardingsphere.proxy.frontend.mysql.command.query.text.query.MySQLComQueryPacketExecutor.<init>(MySQLComQueryPacketExecutor.java:52)
at org.apache.shardingsphere.proxy.frontend.mysql.command.MySQLCommandExecutorFactory.newInstance(MySQLCommandExecutorFactory.java:73)
at org.apache.shardingsphere.proxy.frontend.mysql.command.MySQLCommandExecuteEngine.getCommandExecutor(MySQLCommandExecuteEngine.java:60)
at org.apache.shardingsphere.proxy.frontend.command.CommandExecutorTask.executeCommand(CommandExecutorTask.java:97)
at org.apache.shardingsphere.proxy.frontend.command.CommandExecutorTask.run(CommandExecutorTask.java:72)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
[ERROR] 2021-10-22 13:20:03.759 [Connection-10-ThreadExecutor] o.a.s.p.f.c.CommandExecutorTask - Exception occur:
java.lang.UnsupportedOperationException: unsupported table : `EVENTS`
at org.apache.shardingsphere.proxy.backend.text.admin.mysql.MySQLInformationSchemaExecutorFactory.newInstance(MySQLInformationSchemaExecutorFactory.java:52)
at org.apache.shardingsphere.proxy.backend.text.admin.mysql.MySQLAdminExecutorFactory.newInstance(MySQLAdminExecutorFactory.java:95)
at org.apache.shardingsphere.proxy.backend.text.admin.DatabaseAdminBackendHandlerFactory.newInstance(DatabaseAdminBackendHandlerFactory.java:78)
at org.apache.shardingsphere.proxy.backend.text.TextProtocolBackendHandlerFactory.newInstance(TextProtocolBackendHandlerFactory.java:86)
at org.apache.shardingsphere.proxy.frontend.mysql.command.query.text.query.MySQLComQueryPacketExecutor.<init>(MySQLComQueryPacketExecutor.java:52)
at org.apache.shardingsphere.proxy.frontend.mysql.command.MySQLCommandExecutorFactory.newInstance(MySQLCommandExecutorFactory.java:73)
at org.apache.shardingsphere.proxy.frontend.mysql.command.MySQLCommandExecuteEngine.getCommandExecutor(MySQLCommandExecuteEngine.java:60)
at org.apache.shardingsphere.proxy.frontend.command.CommandExecutorTask.executeCommand(CommandExecutorTask.java:97)
at org.apache.shardingsphere.proxy.frontend.command.CommandExecutorTask.run(CommandExecutorTask.java:72)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
[INFO ] 2021-10-22 13:20:38.681 [Connection-8-ThreadExecutor] o.a.s.p.b.t.a.m.e.i.AbstractSelectInformationExecutor$DefaultSelectInformationExecutor - Actual SQL: ds_0 ::: select `ENGINE`, `SUPPORT` from information_schema.Engines

Reason analyze (If you can)

Steps to reproduce the behavior, such as: SQL to execute, sharding rule configuration, when exception occur etc.

Example codes for reproduce this issue (such as a github link).

The following is my configuration in Proxy.

server.yaml

mode:
type: Cluster
repository:
type: ZooKeeper
props:
namespace: governance_ds
server-lists: localhost:2181
retryIntervalMilliseconds: 500
timeToLiveSeconds: 60
maxRetries: 3
operationTimeoutMilliseconds: 500
overwrite: true
rules:
- !AUTHORITY
users:
- root@%:root
- sharding233@:sharding233
provider:
type: ALL_PRIVILEGES_PERMITTED
- !TRANSACTION
defaultType: XA
providerType: Atomikos
props:
max-connections-size-per-query: 1
kernel-executor-size: 16
proxy-frontend-flush-threshold: 128
proxy-opentracing-enabled: false
proxy-hint-enabled: false
sql-show: false
check-table-metadata-enabled: false
lock-wait-timeout-milliseconds: 50000
show-process-list-enabled: false
proxy-backend-query-fetch-size: -1
check-duplicate-table-enabled: false
sql-comment-parse-enabled: false
proxy-frontend-executor-size: 0
proxy-backend-executor-suitable: OLAP

config-sharding.yaml

schemaName: sharding_db
dataSources:
ds_0:
url: jdbc:mysql://localhost:3306/test?serverTimezone=GMT%2b8&useSSL=false
username: root
password: 123456
connectionTimeoutMilliseconds: 30000
idleTimeoutMilliseconds: 60000
maxLifetimeMilliseconds: 1800000
maxPoolSize: 50
minPoolSize: 1
rules:
- !SHARDING
tables:
tb_result3_sharding_sphere:
actualDataNodes: ds_0.tb_result3_sharding_sphere_$->{1..366}
tableStrategy:
standard:
shardingColumn: datadate
shardingAlgorithmName: tb-result3-class-based
keyGenerateStrategy:
column: tb_result3_id
keyGeneratorName: snowflake
bindingTables:
- tb_result3_sharding_sphere
defaultDatabaseStrategy:
none:
defaultTableStrategy:
none:
shardingAlgorithms:
tb-result3-class-based:
type: CLASS_BASED
props:
strategy: STANDARD
algorithmClassName: com.sg8000.spi.TbResult3ShardingAlgorithm
keyGenerators:
snowflake:
type: SNOWFLAKE
props:
worker-id: 1