Hi, Chris Thank you for your sharing, and I salute your ongoing passion for code refactoring. After studying the related code, I believe there are four tasks that need to be done:
* Remove xxNodeCommandLine: It seems that these classes are indeed redundant, and their previous multi-round mutual calls with xxNode are confusing. I look forward to your clear refactoring. * Refactor the start-up commands of datanode and confignode using commons cli: The concept of SBOM has been quite popular recently, and IoTDB is currently trying to control the introduction of new dependency packages to avoid some potential compliance risks. I checked our POM file and found that we have already depended on commons cli, so this change will not bring new dependency packages, and I fully support doing this, which will be much more elegant than the current manual judgment of strings. * Change the start and stop commands: Currently, when upgrading, we often recommend that users update the lib directory and the sbin directory synchronously, but I just checked the iotdb official website and did not find any relevant documentation on upgrades. I think as long as we have synchronized updates for all scripts, there will be no problem. I can take charge of promoting the update of user upgrade documentation to avoid problems when users upgrade. * AINode: After AINode is open-sourced in the future, we need to go through the above work again for AINode. What are your thoughts? Best ------------- Xinyu Tan On 2024/08/12 08:06:34 Christofer Dutz wrote: > I think it’s unfortunately a bit core to many of the design-decisions being > made in IoTDB. > Many tasks seem to be done in too short time and quite often people are not > taking the required “step back” in order to create a good overall > architecture. > I am seeing this in way too many places in the config-node and data-node > modules. > > My proposal would be to completely rewrite the code for the starting and > stopping of the data- and config nodes. This wouldn’t be as much work as it > sounds, a I would personally base it on Apache Commons CLI. This way we would > have a much cleaner and better tested command-line. > > However, the syntax would change. > > “DataNode -s” > > Would become something like: > > “DataNode start” > > And: > > “DataNode -r 42” > > Would become something like: > > “DateNode -nodeId 42 remove” > > > Chris > > Von: liyuheng <liyuheng55...@126.com> > Datum: Freitag, 9. August 2024 um 05:54 > An: dev@iotdb.apache.org <dev@iotdb.apache.org> > Betreff: Re: [DISCUSS] Refactor ConfigNode and DataNode to be the > command-line instances? > Hi Chris, > > I also feel that extracting separate DataNodeCommandLine and > ConfigNodeCommandLine classes is not really necessary. > > When observing the DataNode startup process, although the main function is in > DataNode, it needs to first go around to DataNodeCommandLine and then back to > DataNode. This convoluted call process confuses me. Perhaps this is an > attempt to separate the command line from the main class? Or maybe this is > just a history design? > > Anyway, I'm looking forward to you simplifying the logic here. > > LiYuHeng > > > 2024年8月7日 22:42，Christofer Dutz <christofer.d...@c-ware.de> 写道： > > > > Hi all, > > > > while working on cleaning up on some config-node removal, I am struggling a > > bit with the structure of our code. > > For example, the main entry point for a program is “DataNode” and > > “ConfigNode”, but the main methods, redirect control to a “commandline” > > instance. > > Depending on the command issued, the commandline then needs to reference > > back to the same instance that called the commandLine do to some other > > things. > > > > I think as both DataNode and ConfigNode only implement an mbean interface, > > it would be cleaner to move the CLI stuff into the main classes and move > > the stuff for starting and stopping nodes into “command” implementations > > for the CLI? This mixture is hard to test and maintain. > > > > Also, could the think about basing the CLI on Apache Commons CLI, however > > that could bring changes in output with it. > > > > What do you others think? > > > > Chris >
