You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Now, it was found that when the local index of the sharding table was created, the index name was specially rewritten. The rewriting logic is as follows:
actual local index name (user_id_idx_t_order_0) = logical local index name (user_id_idx) + "_" + sharding real table name (t_order_0)
During metadata loading, IndexReviser is used to decorate the loaded raw metadata. The currently implemented classes include:
EncryptIndexReviser: decorate the columns involved in the index and convert the actual columns into logical columns;
ShardingIndexReviser: Decorate the index name. Only indexes ending with the actual table name will be decorated as logical indexes. Other index ShardingSphere are not managed, which will cause PRIMARY and user-defined indexes to fail to load into the ShardingSphere;
SingleIndexReviser: decorate the index name, remove the suffix of the single table name, and use the index name in the DB without the suffix;
In addition to the above problems, there are also some questions about why the index name in the sharding table needs to be rewritten? In MySQL, the index is at the table level, and as long as the same name index is not created in the same table, it can be created successfully.
IndexToken and IndexTokenGenerator logic adjustment——Considering that only PG and Oracle index name is unique within the schema range, MySQL/SQLServer do not have similar requirements, you can consider adjusting the sharding table index rewriting logic to only PG and Oracle databases support rewriting (if the PG/Oracle database is only sharded, it does not need to be rewritten), and other databases do not need to be rewritten.
IndexToken is currently used as long as the sharding feature, the index will be suffix rewriting, which is unreasonable for single tables and broadcast tables , the need to remove the logic.
IndexReviser logic adjustment——Delete the logic related to SingleIndexReviser, and there is no need to rewrite or decorate the index name for a single table.
The text was updated successfully, but these errors were encountered:
Feature Request
Is your feature request related to a problem?
No
Describe the feature you would like.
Background
Now, it was found that when the local index of the sharding table was created, the index name was specially rewritten. The rewriting logic is as follows:
actual local index name (user_id_idx_t_order_0) = logical local index name (user_id_idx) + "_" + sharding real table name (t_order_0)
During metadata loading, IndexReviser is used to decorate the loaded raw metadata. The currently implemented classes include:
In addition to the above problems, there are also some questions about why the index name in the sharding table needs to be rewritten? In MySQL, the index is at the table level, and as long as the same name index is not created in the same table, it can be created successfully.
Reference https://stackoverflow.com/questions/27306539/at-what-level-do-postgres-index-names-need-to-be-unique , in PostgreSQL, the index name needs to be unique in the schema, so when sharding tables in PostgreSQL create indexes, the actual table name needs to be used as a suffix to ensure that the index name is unique in the schema.
Solution
IndexToken and IndexTokenGenerator logic adjustment——Considering that only PG and Oracle index name is unique within the schema range,
MySQL/SQLServer
do not have similar requirements, you can consider adjusting the sharding table index rewriting logic to only PG and Oracle databases support rewriting (if the PG/Oracle database is only sharded, it does not need to be rewritten), and other databases do not need to be rewritten.IndexToken is currently used as long as the sharding feature, the index will be suffix rewriting, which is unreasonable for single tables and broadcast tables , the need to remove the logic.
IndexReviser logic adjustment——Delete the logic related to SingleIndexReviser, and there is no need to rewrite or decorate the index name for a single table.
The text was updated successfully, but these errors were encountered: