Fly*_*eep 22 python sqlalchemy
我的Flask-Restful应用程序有许多"对象".在应用程序的第一个版本中,这些是没有行为的简单数据结构,实现为Dicts或Dicts列表.
这些"对象"的属性可以改变.我使用生成器函数来跟踪更改,然后通过服务器发送事件(SSE)警告Web客户端.这通过维护要跟踪的对象的"旧"副本并将其与最新状态进行比较来工作.
在应用程序的下一个版本中,我使用SQLAlchemy从SQLite数据库填充"对象".这些对象现在实现为SQLAlchemy声明性类或此类的列表.
为了比较基于属性相等的"旧"和"新"实例,我只需要__eq__为我的SQLAlchemy对象添加一个覆盖.即,当属性具有相同的值时,实例被认为是相等/不变的.(我已在此问题的底部发布了示例代码).
从技术上讲,这是有效的,但引起了一些建筑警钟:我是否朝错误的方向航行？
a)如果我添加__eq__并__ne__覆盖SQAlchemy对象,当我后来想要将对象重新保存回数据库时,这是否会导致SQLAlchemy出现问题？
b)SQLAlchemy对象应该在我的应用程序中达到多远:是否有"pythonic最佳实践"？即,使用与DB持久性无关的业务逻辑/行为(例如跟踪更改)扩展SQLAlchemy对象是否正常/正常; 或者它们应该仅用作数据库和服务器之间的简单DTO,还有其他对象中的业务逻辑？
注意:我很清楚,通过REST apis和SSE呈现给客户端的数据应该从Web服务器和数据库中的实现细节中抽象出来,因此这不是这个问题的一部分.
sqlalchemy id equal 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-反模式部分-4-持久性域模型/
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)
我将深入了解 Base 类背后发生的事情，以表明__eq__和__ne__覆盖是好的。当您Base通过调用实例化您的类时declarative_base()，它在幕后使用一个元类来设置它（可能值得阅读这个解释这个元类解释以更好地理解为什么涉及它）。它执行一些可配置的设置，例如向您的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生命周期的程度。对我来说，似乎 Alchemy 的“魔法”已经从模型本身中抽象出来了，当会话处理得当时，它们离数据层足够远，感觉类中的业务逻辑不会进入道路。