Closed linghengqian closed 3 years ago
Hi @linghengqian , I'm not sure what's wrong for now, looks there's a mistake?
tb_result3_sharding_sphere_$->{0..366}
means there're 367
shards, seems not match autoTablesAmount = 366
.
Could you debug and set breakpoint on OrderByValue.getOrderValuesCaseSensitiveFromTables
, when NPE thrown, verify:
tableMetaData
null? If it's true, why schema.get(tableName)
return null?tableName
valueAnd could you supply a demo (and create table sql) to reproduce this issue?
Hi @linghengqian , I'm not sure what's wrong for now, looks there's a mistake? means there're shards, seems not match .
tb_result3_sharding_sphere_$->{0..366}``367``autoTablesAmount = 366
Could you debug and set breakpoint on , when NPE thrown, verify:
OrderByValue.getOrderValuesCaseSensitiveFromTables
- is null? If it's true, why return null?
tableMetaData``schema.get(tableName)
- what's value
tableName
And could you supply a demo (and create table sql) to reproduce this issue?
Thank you for your answer, it is indeed that my configuration file is wrong. Change
spring:
shardingsphere:
rules:
sharding:
tables:
tb_result3_sharding_sphere:
actual-data-nodes: ds0.tb_result3_sharding_sphere_$->{0..366}
to
spring:
shardingsphere:
rules:
sharding:
tables:
tb_result3_sharding_sphere:
actual-data-nodes: ds0.tb_result3_sharding_sphere_$->{1..366}
The main reason is that when I created the table according to the rules of the custom sharding algorithm, tb_result3_sharding_sphere_0 was not created. The problem has been resolved, I will close this issue.
Bug Report
For English only, other languages will not accept.
Before report a bug, make sure you have:
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-beta
Which project did you use? ShardingSphere-JDBC or ShardingSphere-Proxy?
ShardingSphere-JDBC
Expected behavior
The following sql is executed normally.
The following is the configuration of application.yml.
The following is the corresponding class of algorithmClassName mentioned in application.yml.
Actual behavior
An NPE exception was thrown during execution.
Reason analyze (If you can)
Then I tested the Order By DESC version and the Oreder By non-shard key SQL, which also threw an NPE exception.
Take the error message with order by as a non-sharding key as an example.
At first I thought that my configuration was wrong, but the SQL without Order By was executed normally, such as the following sentence.
I noticed that this NPE comes from "Map<String, ColumnMetaData> columns = tableMetaData.getColumns();" of "org.apache.shardingsphere.sharding.merge.dql.orderby.OrderByValue.getOrderValuesCaseSensitiveFromTables", but I'm not very much for further reasons sure.
This SQL corresponds to a logical table like the following. According to the settings in application.yml, there are 366 such actual tables.
A key point may be that the actual table retrieved by ShardingJDBC based on the logical table, the column to be checked by this actual table may be 0 column.
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).