Some suggestions about memory mode (in ShardingSphere-JDBC) which has been removed since V5.2.0 according to Issue #19001

[Q2K3]

As above, memory mode has been removed since V5.2.0. Using it in V5.2.0 or higher version (not test yet) will get an exception with message below

SPI-00001: No implementation class load from SPI org.apache.shardingsphere.mode.manager.ContextManagerBuilder with type Memory.

Things about why 'memory mode' was suddenly and quietly removed without compatibility are another question to care about later. But now there are some points I want to suggest:

• Adding clear log which removing memory mode into V5.2.0 release log. (help user realize removing directly)
• Adding clear highlight which removing memory mode in V5.2.0 and higher version document. (good documents should alert user about deprecated or removing features)
• Last, there are some official examples in tag V5.2.0 / V5.2.1 (not cover all) still using memory mode in application.properties file. examples mentioned above seem not to work as expect. I suppose there has need to recheck examples and fix them.

Thks for all contributors in this project and waiting for your response and discussion.

[linghengqian]

• Isn't this just a common name change? The memory mode is almost equivalent to the h2database storage in the standalone mode, and both use h2database to operate metadata. However, the standalone mode is designed to store metadata in relational databases other than h2database, such as MySQL and TiDB.

• If you don't understand, you can note #19964 . As early as the 5.1.x milestone, the memory mode refers to using h2database to store metadata.

• If you expect to submit a PR for an old version of the document, this is impossible because the old versions of the document have been sealed as git tags and svn tags and submitted to the ASF side, and no further changes are allowed.

[Q2K3]

• Isn't this just a common name change? The memory mode is almost equivalent to the h2database storage in the standalone mode, and both use h2database to operate metadata. However, the standalone mode is designed to store metadata in relational databases other than h2database, such as MySQL and TiDB.
• If you don't understand, you can note Update H2DataBase to 2.x and drop support for H2Database 1.x #19964 . As early as the 5.1.x milestone, the memory mode refers to using h2database to store metadata.
• If you expect to submit a PR for an old version of the document, this is impossible because the old versions of the document have been sealed as git tags and svn tags and submitted to the ASF side, and no further changes are allowed.

Thks for so fast reply. I get your point that memory mode in the older version is actually a specific state of standalone mode with h2 db, so in the newer version it has been removed. In my situation, I'm using shardingshpere-jdbc-core-spring-boot-starter(V5.2.1) in my springboot project, I follow the official examples which I metioned above to combine data sharding features into my project. And I found those examples In V5.2.0/V5.2.1 still use memory mode in there configuration files.

Then exception I metioned above occured. Then I started searching infomation about memory mode, there has no obivious log infomation about memory mode removing in offcial release log and document. At last, I found some discussion in the issues, then I got memory mode were removed and never used in higher version.

I decide to suggest about clearly writing out that memory mode was replaced by standalone mode in normal and direct place like offcial release log or document, not just in issues list. That's all why I submit this issue.

BYW, I know that code after tagging cannot be changed again, but official examples with obivious errors (like examples in V5.2.0/V5.2.1 still using memory mode) are very confusing. Maybe there can be some way to resolve this situation

[linghengqian]

I decide to suggest about clearly writing out that memory mode was replaced by standalone mode in normal and direct place like offcial release log or document, not just in issues list. That's all why I submit this issue.

BYW, I know that code after tagging cannot be changed again, but official examples with obivious errors (like examples in V5.2.0/V5.2.1 still using memory mode) are very confusing. Maybe there can be some way to resolve this situation

• There are two common practices under normal circumstances. One is to always have a documentation page on the master branch's documentation to point out the breaking changes across versions, like Apache Seata does. But in fact, almost no one on the Committer team has time to read thousands of PRs and issues for a single milestone, which is usually what the release manager does. The current practice of shardingsphere is similar to zstd-jni, but there is a general release summary text for github release. Refer to https://github.com/luben/zstd-jni . Affected by the AI ​​specification of ASF, it is difficult to say whether this text can be allowed to be generated by tools such as ChatGPT.

• For the example module, the development of this module is relatively independent, because normal PR changes will not trigger the CI of the example module, which explains some strange phenomena. There is only nightly CI for the example module, and the current nightly CI of the example module still has problems. PR is welcome.

• I am not the author of the release note at https://github.com/apache/shardingsphere/releases/tag/5.2.0 , so I will ask the PMC who completed the github release. What do you think? CC @strongduanmu .

[github-actions[bot]]

There hasn't been any activity on this issue recently, and in order to prioritize active issues, it will be marked as stale.