mem0ai
Refactor mem0/memory/main.py: Split Monolithic Class into Modular Components for Maintainability
The current implementation of mem0/memory/main.py is excessively large (>2000 lines) and contains most of the extraction, update, and storage logic inside a single class/file. This design significantly reduces readability, testability, and long-term maintainability.
What's the reason behind keeping it as it? If we can all agree this is a bad engineering practice, are there any reason stopping us from refactoring it? I'm happy to help.
Hey @VincentBai-dotcom Thanks for the concerns , could you point exactly what all code seems to be redundant and bad practice( classes functions etc ) ? If you feel like putting up a PR to refactor it , would happy to review it , but before we do it would love to know the specifics of it ( Where we fall short countered with the thing that can improve them ) Thanks !
Right @VincentBai-dotcom I felt the same while going through the code base. The main file inside mem0 folder is massive! If there's a specific reason for it then maybe it's fine otherwise splitting it will be better ig.
Hey @VincentBai-dotcom Thanks for the concerns , could you point exactly what all code seems to be redundant and bad practice( classes functions etc ) ? If you feel like putting up a PR to refactor it , would happy to review it , but before we do it would love to know the specifics of it ( Where we fall short countered with the thing that can improve them ) Thanks !
It's the mem0/memory/main.py file, which contains the main logic of the Extraction and Update phase, as described by the paper. There are two classes, a normal Memory class and its async version.
I will add more specifics on how I would like to break it down later, have a review with you, and then create a PR. How does this sound?