Hi, Chris +1 for gradually unravel singletons~
As for the pr, perhaps we can split the work of refactoring the singleton and adjusting the functional semantics into two separate pull requests (PRs). This way, for the PR focused on refactoring the singleton, our semantics should remain completely consistent with what they were before. For the PR that adjusts the functional semantics, we can concentrate more on the semantics of the adjustment itself. If there are issues, we can continue to fix them or revert to an earlier version for re-implementation, without having to consider the refactoring aspect. What's your opinion? Best ---------- Xinyu Tan On 2024/08/20 13:09:58 Christofer Dutz wrote: > Hi all, > > I have just finished the first PR after we had the discussion about generally > moving away from singletons a few days ago. > > Unfortunately, the first PR I had to deal with was refactoring, so I did this > for DataNode and ConfigNode, which are the heart and the glue-code of the > Data node and Config node. > While for the ConfigNode refatoring there were no issues, for the DataNode > there were isssues related in initializing things in the wrong order. So, my > initial approach didn’t work for DataNode and I undid this. > > I guess for both DataNode as well as ConfigNode (and in the Future AiNode) it > would genereally make more sense to manually create the instances and weave > the application. > > So now my question to you: > Should I also undo my Singleton-changes for the ConfigNode in this PR: > https://github.com/apache/iotdb/pull/13194/files#diff-3a715a0e8500c37dd803c5644ee6e7e4ce988fc4d578658b0ea75287ed03f924R116 > > I’m quite indifferent about it as long as in long term we get rid of the > singletons. > > Chris > >
