StarHuzy commented on issue #28704: URL: https://github.com/apache/shardingsphere/issues/28704#issuecomment-1756656114
> > > * late reply. I won't have time to confirm the real problem until tomorrow. This seems to be related to some issues on the ShardingSphere JDBC 5.4.1 milestone. > > > > > > SpringBoot seems to have no DataSource management in ShardingSphere-jdbc 5.3.2。 How to obtain the DataSource object when adjusting the configuration reading of the Driver to the SPI interface in ShardingSphere-jdbc 5.3.2 ？ But can we refresh the table rule actualDataNodes by obtaining the dataSource？ > > * You must consider that ShardingSphere JDBC 5.3.2 refactors the upstream and downstream ContextManager for SPI extensions to third-party metadata centers. > * I wrote an article at [[Article Contribution] Welcome to Leave Your Article Link Here #12258 (comment)](https://github.com/apache/shardingsphere/discussions/12258#discussioncomment-3917927), which mentioned how to get the real ShardingSphereDataSource to use ContextManager on ShardingSphere JDBC 5.3.0, which You need to actively define a Spring Bean. I am trying to help the downstream understand from a beginner's perspective how ContextManager serves dynamic update requirements like DistSQL. > * This article also mentions how to obtain the ContextManager through Connection when configuring through JDBC Driver. But not long after I noticed that this particular example had a bug at [Fix the problem that JDBC Connection fails collectively after updating metadata in the example of `shardingsphere-v530-jdk8-modern` linghengqian/shardingsphere-contextmanager-explore#3](https://github.com/linghengqian/shardingsphere-contextmanager-explore/issues/3). I haven't figured out how to fix it yet -- even though I'm a ShardingSphere Committer, I have my knowledge blind spots because the master branch's unit tests change very frequently. > * I plan to refactor this article in the foreseeable future and include Examples for ShardingSphere JDBC 5.3.1, 5.3.2, 5.4.0 and 5.4.1. This TODO is documented at https://www.yuque.com/linghengqian/meve2v/ykridze9nguvect5 . Considering that I'm a graduating college student, finding time is difficult for me. > * As a warning, I definitely don't think you should inject any Spring Beans into the algorithmic class implementation of ShardingSphere SPI, which conflicts with the definition of DistSQL. Because the algorithm class must actually be the final class, DistSQL can remove and recreate the algorithm class. > * As a further extension, I exposed the Row Value Expressions SPI at [Make actualDataNodes expose SPI that can define expression with custom rules and add GraalVM Truffle implementation #22899](https://github.com/apache/shardingsphere/issues/22899). This allows for a more flexible way of defining ActualDataNodes. This feature is on the pre-release branch of ShardingSphere 5.4.1. > * Update: The article I mentioned touches on a very unfortunate problem that I have no energy to translate into English, which leads me to assume that you understand Chinese. Hello, I tried many versions today and finally implemented this feature in ShardingSphere JDBC version 5.1.1. The actual data nodes only need to configure the dynamically loaded logical table names to execute SQL on single or JOIN QUERY multiple tables. However, there seems to be a new issue with @ transactional () annotation management transactions. When my msyql connection driver version is mysql connector java 8.0.33, the transaction fails, After I downgraded version 8.0.20, the transaction was successful. Is this the reason for the new features of the version? If I want to use distributed transactions in version 5.1.1, will the above issues cause this issue -- 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: notifications-unsubscr...@shardingsphere.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
