-
Notifications
You must be signed in to change notification settings - Fork 6.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Table name is keyword error #34137
Comments
What is the version |
5.5.1 |
Hi team, I noticed the issue regarding migration failure when using reserved keywords like user or unit as table names. This seems to be related to syntax handling and metadata fetching in ShardingSphere-Proxy during migration tasks. I'd like to contribute by investigating and resolving this issue. Could you please assign it to me? I’ll ensure to follow the contribution guidelines and provide a detailed solution. Looking forward to your approval! |
Great, please go ahead @jasneetsingh6114 |
I wanted to ask if you could provide guidance on how to reproduce the problem. I am currently referencing the ShardingSphere Migration documentation for setting up and to reproduce the error locally. Looking forward to your response. |
You can create a table in source db with keywords, such as user, and then depending on the page: https://shardingsphere.apache.org/document/current/cn/user-manual/shardingsphere-proxy/migration/usage/ The guide starts the migration task so you can reproduce the problem |
Bug Report
For English only, other languages will not accept.
When I use ShardingSphere-proxy for data migration, when the table name is a keyword, such as user or unit, when I use the command:
"MIGRATE TABLE ds_0.user INTO user"
The migration task fails to be created with the following error: ERROR 1064 (42000): You have an error in your SQL syntax: no viable alternative at input 'MIGRATE' near '[@0,0:6='MIGRATE',<449>,1:0]' at line 1.
When I changed it to
“MIGRATE TABLE ds_0.
user
INTOuser
”The task can be created successfully, but the following error message is displayed in the log:
Can not get meta data for table '
user
' when split by range.This seems to be a bug, can you fix this problem?
The text was updated successfully, but these errors were encountered: