> As you described, the current implementation fails to meet the production > requirements. It's not just about "just to increase the level of abstraction
I said production requirements means function lack. > In my opinion, design and quality of the code are very important in software > engineering. Therefore, we should discuss and improve these codes as soon as > possible. More abstraction does not means better code quality but duplicated code. I prefer this word: “Non sunt multiplicanda entia sine necessitate”. let’s make this clear: please do not change the core concept before we release tiered storage. > I suggest that you carefully review the improvement suggestions outlined in > the document I have of course read your proposal before replying. For TieredMetadataStore, I agree metadata store should only care about FileSegmentMetadata, we cloud let FileSegment extend FileSegmentMetadata to make code clear. But it makes sense for each entity to maintain its own metadata, no need to extract FileSegmentMetadata related code to SegmentQueue. For TieredFlatFile/CompositeFlatFile/CompositeAccess, I don't see a need for adding these abstractions in your proposal. We should not refactor until there's a must-have reason. For bug fixes, this is what we need most, and can be fixed directly without waiting for this proposal to be approved. Your response would be highly appreciated. SSpirits Email：ad...@lv5.moe<mailto:ad...@lv5.moe> On 12 May 2023 at 9:16 PM +0800, zhimin li <lizhim...@gmail.com>, wrote: As you described, the current implementation fails to meet the production requirements. It's not just about "just to increase the level of abstraction". In my opinion, design and quality of the code are very important in software engineering. Therefore, we should discuss and improve these codes as soon as possible. At the same time, I am enthusiastic about adding more feature support in the future. Also there are some bugs in the implementation as mentioned in the documentation. Lastly, I suggest that you carefully review the improvement suggestions outlined in the document, then we can discuss specific API design. Best Wishes, Zhimin Li SSpirits <ad...@lv5.moe> 于2023年5月12日周五 16:37写道： There is no benefit in doing such a big refactoring at the current stage just to increase the level of abstraction. This proposal neither facilitates the participation of new contributors (because there is no optimization of FileSegment) nor does it have much-needed new capabilities such as new backend support or timed message support. We can do the refactoring described in this proposal when there are definite reasons. I hope we can focus on improving the feature of tiered storage so that it can be production available as soon as possible. Your response would be highly appreciated. SSpirits Email：ad...@lv5.moe<mailto:ad...@lv5.moe> On 11 May 2023 at 3:26 PM +0800, zhimin li <lizhim...@gmail.com>, wrote: Hello RocketMQ Community: I have reviewed the code related to tiered storage. And I hope to improve the code quality of the tiered storage. Actually turned out to hava a couple of small bugs in it too. There are some interface improvements in metadata management for tiered storage. Here is my detailed design document. https://github.com/apache/rocketmq/wiki/RIP-65-Tiered-Storage-Optimization Please welcome to reply to this email or comment on the proposal if you have any questions or suggestions. Thanks, Zhimin Li
