I have an ORM library for a relational real estate database. The used framework is
peewee. The library contains ~60 models, each representing a distinct table. The models represent a (pre-defined, proprietary) real estate data structure based on XML. There is one top level table called immobilie (real estate), which represents the root of the XML document.
Each model has defined the classmethods
from_dom(cls, dom) and
from_dict(cls, dictionary) and methods
to_dict(self) which contain a considerable amount of code.
The library works fine as it is, but the module currently has 10255 lines of code, which makes it quite hard to read and maintain.
My idea thus was to split the module into several smaller modules, each for one model. This, however, creates the following problems:
peewee requires setting the respective foreign key's model in the respective model definition. For simplicity of presentation let's assume:
class Parent(Model): @property def semi_orphans(self): return Child.select().where( (Child.mom == self & Child.dad >> None) | (Child.mom >> None & Child.dad == self)) class Child(model): mom = ForeignKeyField(Parent) dad = ForeignKeyField(Parent)
Thus the referenced model has to be imported in the respective model definition.
2) As the example with the
semi_orphans property should clarify, nearly all referenced models also need to know their referencing models for certain selection methods.
This would create unresolvable cyclic imports as I already tested with parts of the code.
Thus I thought, I could outsource the backreferencing methods into own subclasses in separate moules. This however would render them unavailable when doing something like:
some_child = Child.get() semi_orphans = some_child.mom.semi_orphans
This would trigger an
some_child.mom would return the base model without the
Am I overlooking something? Is it really impossible to split the library into smaller components to increase its code quality and maintainability because there is no way of getting rid of the cyclic dependencies?