将使用Django ORM在python库中引起麻烦？ [英] Will using the Django ORM in a python library cause trouble?

问题描述

我喜欢使用Django相当多年。现在我正在为一家公司工作，该公司正在构建一些共享内部库，用于从我们的数据库访问信息。现在事情是非常疯狂的 - 大量的内联SQL代码。一些同事正在努力做一些访问代码，我发现这是我习惯了Django做的开箱即用的东西。我也听说Django基本上是模块化的，所以我可以单独使用ORM系统。我知道有像SqlAlchemy这样的其他包，但我也听说Django做事情更容易为一般情况，这可能是我们需要的。我也知道Django，不知道SQLAlchemy。

所以，我可以做一个概念证明，如下所示。这是目录结构：

  +  -  example.py 
 +  -  transfer 
 | +  -  __init__.py 
 | +  -  models.py 
  

这里是models.py

  import django.conf 
 import django.db.models 
 
 django.conf.settings.configure（
 DATABASES = ...，＃database info 
 INSTALLED_APPS =（transfer，），
 SECRET_KEY ='not telling'，
）
 django.setup（）
 b $ b class TransferItem（django.db.models.Model）
＃模型信息here 
  

example.py

  from transfer.models import TransferItem 
 items = TransferItem.objects.all（）
打印项目
  

这看起来工作正常，但我担心在库上下文中的引导代码。具体来说：

1. django有想过这个应用程式吗？在这种情况下，传输是一个根模块，但在库中，这可能被埋没。例如，mycompany.data.protocols.transfer。理论上，我们可以在整个代码库中定义这些数据模型。这个应用列表如何扩展？


2. 设置调用真的让我很担心。 django docs具体说只有调用安装一次。然而，图书馆的本质是任何python应用程序可以导入他们想要的任何类型的数据模型。我不能做出任何假设，他们可能想要的django应用程序，或他们想要的是什么顺序。如果使用一种类型的模型，数据被返回，然后才是python应用程序决定它需要导入
   因此，根本的问题是：





在python库中使用django ORM有很好的方法吗？





EDIT：这是 不 CLI工具问题的副本。我知道如何在web服务器外运行django。我甚至给了代码示例显示这个。我想知道是否有一种方法来运行django，我没有应用程序本身 - 其中模型文件可以通过客户端代码导入并以任何顺序使用。





我可以为我的模型创建一个基础类库中的任何地方，如下所示：

  from django.db import models 
 from django.apps import apps 
 import django.conf 
 
 django.conf_settings.configure（
 DATABASES = ... 
）
 
 apps.populate（（__ name__，）） 
 
 class LibModel（models.Model）：
 class Meta：
 abstract = True 
 app_label = __name__ 
  

然后在库中的任何地方，我可以用这个基础类创建自己的模型。由于我不依赖于数据库名称的应用程序，因此我需要明确说明它们。

  class SpecificModel LibModel）：
＃字段到这里
类Meta（LibModel.Meta）：
 db_table =specific_model_table_name
  

这让我想到必须模拟应用程序的结构。基类中的名称属性为Django提供了它所需要的全部内容，然后Django就不再发现应用了。其他模型文件可以放在任何他们想要的地方。





然而，仍然有一个很大的担忧，我可能是致命的。 Django的初始化本身仍然是单例。如果我的库本身是由Django应用程序导入的，它会崩溃和烧毁。我在此后续问题。




I've enjoyed using Django quite a bit over the years. Right now I'm working for a company that is building some shared internal libraries for accessing information from our databases. Right now things are terribly sloppy - lots of inline SQL code. Some colleagues were working on doing some accessing code, and it occurred to me that this is the sort of thing that I'm used to Django doing out of the box. I had also heard that Django is fundamentally modular, so that I could just use the ORM system in isolation. I know there are other packages for this like SqlAlchemy, but I also hear that Django does things easier for the average case, which is likely all we'll need. I also know Django, and don't know SQLAlchemy.

So, I can do a proof of concept, like the following. Here is the directory structure:

+-- example.py
+-- transfer
|   +-- __init__.py
|   +-- models.py

Here is models.py

import django.conf
import django.db.models

django.conf.settings.configure(
    DATABASES = ..., # database info
    INSTALLED_APPS = ("transfer",),
    SECRET_KEY = 'not telling',
)
django.setup()

class TransferItem(django.db.models.Model)
    # model info here

example.py

from transfer.models import TransferItem
items = TransferItem.objects.all()
print items

This seems to work fine, as far as it goes. But I'm worried about the bootstrap code in a library context. Specifically:

1. Is there danger in django thinking of this as an app? In this case, "transfer" is a root module, but in a library context this could be buried deep. For example, "mycompany.data.protocols.transfer". Theoretically, we could have these data models defined throughout the codebase. How can this "app list" scale?
2. The call to setup really worries me. The django docs specifically say only to call setup once. And yet the nature of a library is that any python application could import whatever type of data model they want. I can't make any assumptions about which django "apps" they might want, or what order they want it in. Would if one type of model is used, data is returned, and only then does the python application decide it needs to import another type of model (quite possibly in a different "app")?

So, the fundamental question is this:

Is there a good way to use django ORM in a python library?

EDIT: This is not a duplicate of the CLI tool question. I know how to run django outside the web server. I even gave code samples showing this. I want to know if there's a way to run django where I don't have "apps" per se - where model files could be imported by client code and used in any order.

解决方案

OK, here's my own attempt to answer the question after some research.

I can create a baseclass for my models anywhere in the library as follows:

from django.db import models
from django.apps import apps
import django.conf

django.conf_settings.configure(
    DATABASES = ...
)

apps.populate((__name__,))

class LibModel(models.Model):
    class Meta:
        abstract = True
        app_label = __name__

Then anywhere in the library I can create my own models with this baseclass. Since I'm not relying on the "app" for the database names, I need to state them explicitly.

class SpecificModel(LibModel):
    # fields go here
    class Meta(LibModel.Meta):
        db_table = "specific_model_table_name"

This gets around my concern of having to simulate the structure of an "app". The name property in the base class supplies Django with all it needs, and then Django quits whining about not finding an app. The other model files can live wherever they want.

However, there is still a big concern I have which might be lethal. Django's initialization itself is still singleton in nature. If my library were itself imported by a Django application, it would all crash and burn. I've asked for solutions to this in this follow up question.

这篇关于将使用Django ORM在python库中引起麻烦？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！