terrymanu commented on issue #22433: URL: https://github.com/apache/shardingsphere/issues/22433#issuecomment-5709826454
Hi @vikiuvb, thanks for the proposal. After revisiting the scope, we do not think current ShardingSphere needs this additional abstraction, so we recommend closing this issue as not planned. This is not a bug. If online scaling and automatic topology propagation are out of scope, a data source group only becomes an alias for a repeated data source list. A sharding table currently owns its `actualDataNodes` explicitly, which is an appropriate correctness boundary because different logical tables do not necessarily have the same physical topology. The proposed example also creates a table-specific `t_orders_group`. If every table has its own group, the configuration is moved rather than reduced. A first-class group would add new Java API, YAML, DistSQL, persistence, reference-integrity, and rule-dependency contracts without introducing necessary runtime behavior. Current ShardingSphere already provides the relevant reuse mechanisms: - inline expressions reduce repeated node enumeration; - `defaultDatabaseStrategy` shares a database sharding strategy across tables; - Java and YAML configurations can omit `actualDataNodes` for database-only sharding that uses all configured data sources. A named group would become justified only if multiple table rules share a stable data source subset that has an independent lifecycle and must be managed as a first-class object. The current issue does not demonstrate that requirement. There is a smaller, separate question: DistSQL currently requires `DATANODES`, while Java and YAML can represent an omitted `actualDataNodes`. If this parity is needed, it should be discussed as a focused DistSQL enhancement rather than introducing a new data source group model. We recommend keeping `type: discussion` and `feature: sharding`, and closing this issue as not planned. This request is reasonable, so it should not be labeled invalid. -- 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]
