组织包含SQLAlchemy模型的文件夹的最佳方法

时间:2008-12-12 15:02:25

标签: python orm sqlalchemy

我在工作中使用SQLAlchemy,它确实很好地完成了工作。现在我正在考虑最佳实践。

现在,我创建了一个包含所有SQLA内容的模块:

my_model
        |__  __init__.py 
        |__  _config.py <<<<< contains LOGIN, HOST, and a MetaData instance
        |__  table1.py <<<<< contains the class, the model and the mapper for table1
        |__  table2.py <<<<< contains the class, the model and the mapper for table2
        [...]

现在,我真的不知道这是否是最佳方式。我想以精细的粒度加载类,并确保只与db等创建一个连接。

这里,所有的类都是分开的,但是所有的import _config都是我想知道这是不是一件好事。

更重要的是,我希望能够创建可以独立存储的模型类的子类,而不必每次都搞乱映射器。我怎样才能做到这一点 ?

现在我只是将它们放在同一个文件中,我必须创建另一个映射器,但每次都会调用第一个映射器。如果我必须导入父类,因为在导入时触发了映射器,情况也会如此。如果我不使用该类访问数据,那么每次映射都不会过热吗?

我也想避免使用Elixir。

1 个答案:

答案 0 :(得分:3)

我个人喜欢将数据库/ ORM逻辑保留在模型类之外。这使它们更容易测试。我通常有类似types.py的东西,它定义了我的应用程序中使用的类型,但独立于数据库。

然后通常会有一个db.py或类似的东西,其中包含Session类以及设置数据库所需的其余代码,包括所有映射器等。

除执行数据库操作的模块外,其他模块都不需要导入db模块,并且大多数应用程序类都完全隐藏了数据库的存在。

据我所知,如果不更改mapper,就无法轻松创建子类。在执行查询时,SQLAlchemy无法知道从数据库中检索哪个子类,并且无论如何都需要能够在存储数据时指示子类。

我没有真正看到从主db模块一次调用所有映射器时出现任何问题,所以我不认为始终初始化它们实际上是一个问题,除非您实际将其识别为瓶颈。根据我的经验,其他处理比较小的映射器开销要大得多。

豫ICP备18024241号-1