【问题标题】:Trouble with interfacing PonyORM连接 PonyORM 的问题
【发布时间】:2018-03-21 17:26:13
【问题描述】:

我发现 Pony 是用于小型项目的好工具。但是,当您的项目发展到一定程度时,在您的函数中放置 @db_session 几乎对于编写的每个函数都是强制性的。

遵循 SOLID 原则,我正在尝试连接 PonyORM。然而,事情并没有我想象的那么容易。

class CustomQuery(object):
    def __init__(self, query):
        self.obj = query

    def __getattr__(self, attr):
        return getattr(self.obj, attr)

    @db_session
    def count(self):
        return self.obj.count()

    @db_session
    def first(self):
        return self.obj.first()

    @db_session
    def without_distinct(self):
        return self.obj.without_distinct()

    def __iter__(self):
        return self.obj.__iter__()


class DatabaseService:

    @staticmethod
    @db_session
    def select(*args):
       # This will be select() interface
        return CustomQuery(select(*args))

这是我尝试做的一个例子。但是,当我执行以下操作时遇到了问题:

# User has many PhoneNumbers

user = User.select().first() 

assert isInstance(user, CustomQuery)

user.phone_numbers.count()

如果我理解正确,在执行user.phone_numbers.count() 时会创建一个新的pony.orm.core.Query 对象。

我想改为返回一个 CustomQuery 对象,这将允许 db_session 持续存在。

对如何做到这一点有任何想法吗?或者其他人处理过@db_session 装饰器的任何其他方式?

【问题讨论】:

    标签: ponyorm


    【解决方案1】:

    首先,在我看来,您试图与 Pony 的设计理念作斗争:@db_session 装饰器的整个想法是让您不必处理数据库管理(样板代码、打开/关闭 DB、SQL、回滚等),我知道您想自己做,因此使@db_session 的想法没有实际意义

    其次,本质上,除非装饰器在调用时有副作用,否则它只是一个以调用开始和结束的包装器。因此,让它持续存在的想法也与其预期目的相反。

    总而言之,如果你想做 pony 提供给你的设施的工作,你最好干脆放弃使用 pony。

    也许,你应该问自己为什么要小马以及为什么要摆脱装饰器。下定决心将帮助您做出正确的决定。

    HTH

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2014-11-04
      • 2013-07-11
      • 2014-12-20
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多