Sqlalchemy declarative可安全重写方法及组合方案适用性咨询

如何判断方法是否可安全重写 #

SQLAlchemy为Declarative Base生成的魔法方法，核心是服务于ORM的对象状态跟踪、会话管理、数据库记录匹配逻辑，判断能否重写的核心原则是：你的重写逻辑是否会破坏ORM依赖的内部身份判断规则

• 可放心重写的方法：__hash__、__eq__、__repr__、__str__、__iter__、__bool__这类不涉及ORM核心属性操作的方法。其中重写__hash__时只要和你自定义的__eq__逻辑对齐即可，SQLAlchemy内部判断对象对应数据库记录时，依赖的是实例自带的_sa_instance_state存储的主键、会话标识等信息，完全不会受用户自定义的__eq__、__hash__影响。
• 需谨慎重写的方法：__getattr__、__setattr__、__getattribute__、__init__这几个和属性操作、实例初始化相关的方法。SQLAlchemy的懒加载、属性变更跟踪逻辑全依赖这几个方法的默认实现，若需重写必须在方法开头先调用父类的对应实现，比如重写__setattr__要先执行super().__setattr__(name, value)，重写__init__要先调用super().__init__(**kwargs)，否则会直接破坏ORM的属性映射逻辑。
• 禁止重写的方法：所有以_sa_开头的SQLAlchemy私有方法，以及__getstate__、__setstate__这类序列化相关的方法，SQLAlchemy靠这些方法实现会话持久化、对象状态序列化，修改后极易出现会话丢失、状态异常等难以排查的问题。

继承重写还是组合方案 #

没有强制要求必须使用组合，大部分场景下继承重写是成本更低的方案，只要遵守上述重写规则即可。
组合方案仅推荐在以下场景使用：你的原有Python对象和ORM映射模型差异极大，比如原有对象存在大量和数据库字段无关的业务方法、属性，或者需要严格隔离业务逻辑层和ORM层，这种时候用组合的隔离收益远高于写一堆@property的成本。如果只是要修改少量魔法方法，完全没必要使用组合，直接在继承自Base的模型类中重写对应方法即可，不会对SQLAlchemy运行产生任何影响。

示例合法重写代码：

from sqlalchemy.orm import DeclarativeBase
from sqlalchemy import Column, Integer, String

class Base(DeclarativeBase):
    pass

class User(Base):
    __tablename__ = "user"
    id = Column(Integer, primary_key=True)
    name = Column(String)

    # 自定义__eq__逻辑
    def __eq__(self, other):
        if not isinstance(other, User):
            return False
        return self.id == other.id and self.name == other.name

    # 和__eq__逻辑对齐重写__hash__
    def __hash__(self):
        return hash((self.id, self.name))

    # 自定义打印格式
    def __repr__(self):
        return f"User(id={self.id}, name={self.name})"

内容的提问来源于stack exchange，提问作者John Brodie