7

背景: 5 つの独立した Django プロジェクトがあり、複数のアプリで構成される 1 つの Django プロジェクトに結合しようとしています。つまり、projA には appA、projB には appB、projC には appC などがあります。appA、appB、appC を持つ masterProj が 1 つ必要です。

現在、各アプリは独自の独立したデータベースに接続しています (アプリはデータを共有しません)。各プロジェクトは、Django ユーザー認証、Django 登録、taggit、プロファイル、コメント、および sorl-thumbnail を使用します。

私はDjango 1.4を使用しており、このスタックオーバーフローの回答に従ってデータベースルーティングをセットアップしているため、1つのプロジェクトに結合されると、新しく結合されたDjangoプロジェクトの各アプリは引き続き独自のデータベースに接続できます。それはスムーズに進みましたが、ユーザー認証や taggit などで問題が発生し始めました。

1)前述のように、各アプリは異なるデータベースに接続し、それらの各データベースには「auth_user」という名前のテーブルがあります。ただし、auth_user テーブルへのすべての読み取り/書き込み呼び出し (読み取り/書き込み呼び出しを行うアプリに関係なく) は、既定のデータベース (この場合は appA のデータベース) にルーティングされることがわかりました。

# settings.py:
DATABASES['default'] = DATABASES['appA']
DATABASE_ROUTERS = ['appA.db.DBRouter', 'appB.db.DBRouter', 'appC.db.DBRouter']

# appA/dbrouterA.py (appB, appC routers are identical this, replacing 'appA' with 'appB', etc.)
class DBRouter(object):
    def db_for_read(self, model, **hints):
        if model._meta.app_label == 'appA':
            return 'appA'
        if model._meta.app_label == 'auth':
            return 'appA'
        return None

    def db_for_write(self, model, **hints):
        if model._meta.app_label == 'appA':
            return 'appA'
        if model._meta.app_label == 'auth':
            return 'appA'
        return None

2） ルーティングが機能すると仮定すると、ユーザーが appA にログインした場合、 appB にログインしたくありません。多くの人が逆の質問を投稿しているのを見てきました (アプリでユーザー資格情報を共有したい) が、同じプロジェクト内のいくつかの独立したアプリで Django ユーザー認証を正常に使用した人はいますか? もしそうなら、どうやってこれをしましたか？

3) taggit コードから次のエラーが表示されますが、"related_name" パラメーターを taggit に渡す方法がわかりません。私は taggit の基本的な実装を使用しています - 何もサブクラス化していません:

# appA/models.py
tags = TaggableManager(blank=True)

# appB/models.py
tags = TaggableManager(blank=True)

エラー：

appA.userprofile: Accessor for m2m field 'tagged_items' clashes with related m2m field 'TaggedItem.userprofile_set'. Add a related_name argument to the definition for 'tagged_items'.
appB.userprofile: Accessor for m2m field 'tagged_items' clashes with related m2m field 'TaggedItem.userprofile_set'. Add a related_name argument to the definition for 'tagged_items'.

4)これらのアプリをすべて組み合わせるのは、滑りやすい坂道だと感じ始めています。後で、sorl-thumbnail またはまだ表面化していないコメントで問題が発生する可能性があります。アプリを 1 つのプロジェクトにうまく組み合わせた人はいますか? それとも、Django が基本的にサポートしていないことをしようとしているのですか?

助けてくれてありがとう！

4

1 に答える 1

1

Django のアーキテクチャは、Django プロジェクトといくつかの Django アプリケーションを中心に展開するように設計されています。プロジェクト自体は設定とメインの URL 構成モジュールにすぎませんが、アプリケーションはいくつかのファイル規則に従う単純なパッケージです。

現在、アプリケーション自体が特定のプロジェクトに結合されることはありません (ただし、アプリケーションを参照することで他のアプリケーションに結合することはできます)。これは、プロジェクトのソースがどのように構造化されているかを自由に設計できるようにすることを目的としています。ほとんどの Django プロジェクトに共通するアプローチの 1 つは、ほとんどの Python アプリケーションと同様に、プロジェクトの最上位パッケージで Django アプリケーションを配布することです。このアプローチにより、プロジェクトが提供するすべての機能の全体像を把握し (意味のあるアプリケーションのラベル付けを適用する場合)、名前空間を作成し、特定のプロジェクト ソースへの便利で整理されたアクセス パスを開発者に提供することが容易になります。

これは、大規模なプロジェクトでも、同様の設計とアプローチを再利用するいくつかの異なるプロジェクトを併置してマージする場合でもうまく機能します。これはプロジェクトの構造にのみ影響しますが、Django アプリケーションの固定セット用に単一の Django プロジェクトまたは複数の Django プロジェクトの構成を持つかどうかの選択には、いくつかの重要な影響があります。

Django プロジェクトを作成するときは、基本的に Django アプリケーションをフレームワークのインストルメンテーションにプラグインし、Django アプリケーションからの URL とビューのマッピング パターンを構成して含めることにより、Web アプリケーションで理解しているように、アプリケーションの動作を公開します。

要点は、自分に合った方法でソースを再編成できるということです。パッケージは、 、 、 、 、 、 、 、 、 、 、、、、、のようproj.appAに編成できます。proj.appBproj.common1proj.common2proj.projA.app1proj.projA.app2proj.projB.app1

知っておくべきことは、単一の設定と URL モジュールを必要とせず、データベース ルーティングとデータベース接続の管理に頼るのではなく、プロジェクトごとに異なるアプリケーションを参照し、異なる動作を公開する設定と URL モジュールを持つこともできるということです。 . プロジェクトごとのデータベース設定を使用すると、既にコードを再利用し、データベースのデータと状態をプロジェクトごとに区別して維持できます。

于 2012-06-09T15:15:03.930 に答える