Question

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

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

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

为了比较基于属性相等的“旧”和“新”实例，我只需要添加__eq__覆盖我的SQLAlchemy对象。即，当属性具有相同值时，实例被认为是相等/不变的。（我已在此问题的底部发布了示例代码）。

从技术上讲，这是有效的，但会引发一些建筑警报：我是否朝错误的方向航行？

a）如果我向SQAlchemy对象添加__eq__和__ne__覆盖，当我以后想要这会导致SQLAlchemy出现问题将对象重新保存回数据库？

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

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

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__覆盖正常。当您通过调用Base实例化declarative_base()类时，它会在幕后使用元类来设置它（可能值得阅读此解释this metaclass explanation以更好地理解它涉及的原因）。它执行一些可配置的设置，例如向Base类添加自定义构造函数，并设置它将如何从对象映射到表。

然后

declarative_base()将返回Base元类的新DeclarativeMeta类实例。这里涉及元类的全部原因是，当您创建扩展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生命周期。对我而言，似乎足够的炼金术“魔法”从模型本身中被抽象出来，当会话处理得很好时，它们与数据层相距足够远，以至于它不会觉得类中的业务逻辑会进入方式。

比较SQLAlchemy对象实例以确定属性的等同性

1 个答案: