jpenalver10 commented on issue #37572:
URL:
https://github.com/apache/shardingsphere/issues/37572#issuecomment-3698684243
Thanks for you answer.
Ok, I understand this behaviour is not the designed for the library, not the
intended use, so perhaps I have to think another way to dinamically change the
sharding algorithm (via external properties, etc).
Anyway, in my proof of concept I defined the DB table that contains the
sharding information as SINGLE, so the recursion risk during the resolution is
low, as sharding algorithm always query the main shard and is not recursively
called itself --> `main.db_sharding.*`:
```
rules:
- !SINGLE
tables:
- main.outbox_dm_tables.*
- main.db_sharding.*
- main.non-existing
defaultDataSource: main
```
Regarding this config, if you'll allow me, I want to do a question about the
definition format of tables:
- `main.outbox_dm_tables.*` this would means "All tables from
outbox_dm_tables schema goes to main shard"?
- `main.db_sharding.sharding_tenant_config` this would means "Only the table
sharding_tenant_config from db_sharding schema goes to main shard"?
- As I know, the SINGLE rules are the default beahviour for all tables that
are not defined in other ways (not SHARDING etc) and I have defined a default
data source. It means that all tables in another schema (suppose
`infrastructure`) will be routing by default to main shard? In my config this
happens when I add this rule `main.non-existing` that is intentionally
incorrect, so all tables in a `infrastructure` schema are routing to default,
but if I removed the tablas can't be located by ShardingSphere.
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
