python - 比较 SQLAlchemy 对象实例的属性相等性

Question

我的 Flask-Restful 应用程序有许多“对象”。在应用程序的第一个版本中，这些是简单的数据结构没有行为，实现为字典或字典列表。

这些“对象”的属性可以改变。我使用生成器函数来跟踪更改，然后通过服务器发送事件 (SSE) 向 Web 客户端发出警报。这是通过维护要跟踪的对象的“旧”副本并将其与最新状态进行比较来实现的。

在应用程序的下一个版本中，我使用 SQLAlchemy 从 SQLite DB 填充“对象”。这些对象现在实现为 SQLAlchemy 声明性类或此类类的列表。

要根据属性的相等性比较“旧”和"new"实例，我必须添加一个 __eq__ 覆盖到我的 SQLAlchemy 对象。即当属性具有相同的值时，实例被认为是相等/不变的。(我已经在这个问题的底部发布了示例代码)。

从技术上讲，这是可行的，但会引发一些建筑警钟:我是不是在错误的方向航行？

a) 如果我添加 __eq__ 和 __ne__ 覆盖到 SQAlchemy 对象，这是否会导致 SQLAlchemy 在我以后想要时出现问题将对象重新持久化回数据库？

b) SQLAlchemy 对象应该在我的应用程序中到达多远:是否有“pythonic 最佳实践”？即使用与数据库持久性无关的业务逻辑/行为(例如跟踪更改)扩展 SQLAlchemy 对象是否可以/正常；还是应该仅将它们用作数据库和服务器之间的简单 DTO，在其他对象中包含业务逻辑？

注意:我很清楚，通过 REST api 和 SSE 呈现给客户端的数据应该从网络服务器和数据库中的实现细节中抽象出来，所以这不是这个问题的一部分。

sqlalchemy id equality vs reference equality https://codereview.stackexchange.com/questions/93511/data-transfer-objects-vs-entities-in-java-rest-server-application http://www.mehdi-khalili.com/orm-anti-patterns-part-4-persistence-domain-model/

class EqualityMixin(object):
# extended from the concept in :
# https://stackoverflow.com/questions/390250/elegant-ways-to-support-equivalence-equality-in-python-classes

    def __eq__(self, other):
        classes_match = isinstance(other, self.__class__)
        a, b = deepcopy(self.__dict__), deepcopy(other.__dict__)
        #compare based on equality our attributes, ignoring SQLAlchemy internal stuff
        a.pop('_sa_instance_state', None)
        b.pop('_sa_instance_state', None)
        attrs_match = (a == b)
        return classes_match and attrs_match

    def __ne__(self, other):
        return not self.__eq__(other)

Answer 1

我将深入研究 Base 类背后发生的事情，以表明 __eq__ 和 __ne__ 覆盖很好。当您通过调用 declarative_base() 实例化您的 Base 类时，它在后台使用元类来设置它(可能值得阅读此解释 this metaclass explanation 以更好地了解为什么会涉及)。它进行了一些可配置的设置，例如向您的 Base 类添加自定义构造函数并设置它将如何从对象映射到表。

declarative_base() 将返回一个新的 DeclarativeMeta 元类的 Base 类实例。这里涉及元类的全部原因是，当您创建一个扩展您的 Base 的类时，它会将其映射到一个表。如果您沿着这条路径稍微追溯一下，您将看到它如何将您在对象上声明的列映射到表。

self.cls.__mapper__ = mp_ = mapper_cls(
        self.cls, # cls is your model
        self.local_table,
        **self.mapper_args # the columns you have defined
    )

虽然执行此操作的实际 Mapper 看起来非常复杂和低级，但在此阶段它使用主键和列而不是实际的对象实例进行操作。但是，这并不能确认它从未使用过，因此我查看了源代码中 == 和 != 的用法，没有发现任何值得关注的原因.

至于你的第二个问题，我只能提供我自己的意见——我过去在这个主题上搜索过很多次，并没有发现太多关于“黄金标准”SQL Alchemy 用法的信息。到目前为止，我已经在几个项目中使用了 SQL Alchemy，感觉您对对象的使用可以扩展到您仍然可以明智地抽象出 session 生命周期的程度。对我来说，Alchemy 的“魔法”似乎已经从模型本身中抽象出来了，当 session 处理得很好时，它们与数据层的距离足够远，以至于感觉类中的业务逻辑不会进入路。