0

djangoテストサーバーとapache/wsgi本番環境の違いに常に悩まされています。テストサーバーで完全に機能するコードは、展開後に常に失敗し、デバッグは非常に難しいように思われることがよくあります。今回はそれも見つかりませんdjango.db.models:、(

レンプレート

{{one_medal_owningship.get_medal_name}}

models.py

from django.db import models
class MedalsManager(models.Manager):
    _cache={}

    def get_by_owningship(self,owningship):
        return self.__class__._cache[owningship.medal_id]
    ...

class Medals(models.Model):
    name=models.Charfield(max_length=50)
    objects=MedalsManager()
    ...

class MedalOwningship(models.Model):
    medal=models.ForeignKey('app.Medals')
    user=models.ForeignKey('auth.User')

    def get_medal_name(self):
        return models.get_model("app","Medal").objects.get_by_owningship(self).name #Here is ***the problem***, models is reported as None

import signal_listeners  #I put signal listeners in a separated file and register them here

signal_listeners.py

# site_settings.py is a file in the root of the project for storing some control variables, like the number of posts you can post a day
import site_settings #This is the "cause" of the problem, if I change it to myproject.site_settings then everything works.

これについてインターネットで検索すると、全体像を把握するのが難しい非常に特殊なケースにつながることがよくあります。これらの問題をどのように回避すべきかについての経験則、読書リスト、またはチュートリアルがあるかどうか疑問に思っていますか?また、サーバー環境のセットアップにより、コードに不要なエラーが発生する可能性があります(たとえば、djangoとpythonのバージョンは開発環境と同じです)。どうもありがとう!

更新: 問題はなんとか解決されましたが、原因はわかりません。したがって、上記のコードでは、a_medal_owningship.get_medal_name実行時にエラーが発生し、明らかにその関数のスコープ内にdjango.db.modelsなります。Noneそのmodels.pyファイルにsignal_listenerファイルをインポートしました。site_settings(カスタマイズされた定数ストレージ)をsignal_listenersにインポートする方法をからに変更import site_settingsするimport myproject.site_settingsと、問題は解決します。

ただし、のようにプロジェクトルートから別のランダムファイルをインポートしてimport foobarも、問題はありません。したがって、site_settingsが別の場所にインポートされ、ここにインポートされると問題が発生する必要があります。

カスタマイズされたファイルのインポートがdjangoのデフォルトモジュールとどのように競合する可能性があるので、これは私には意味がありません。import fooそして、との違いは何import myproject.fooですか?

4

2 に答える 2

2

開発サーバーとmod_wsgiの違い、およびwsgi.pyダイレクトに対して実行した場合のgunicornは、繰り返し発生する一般的なテーマです。それは確かに説明するのが難しい問題であり、人々がそれを経験していないという理由だけで問題としてそれを却下しようとすると失望します。これは本当の問題であり、フォーラムで人々を支援するのに十分な時間を費やすと、かなりの問題が発生します。

私自身はDjangoを使用していませんが、問題を理解するために何度か試したので、問題が何であるかを人々にわかりやすく説明できますが、それでも簡単な答えは得られません。

私は以前にこの問題についてブログを書きました:

http://blog.dscpl.com.au/2010/03/improved-wsgi-script-for-use-with.html

基本的な問題は、管理コマンドがロードされることにより、開発サーバーがDjangoアプリケーションの大部分をプリロードし、特定の順序で実行するという事実に帰着します。

mod_wsgiとgunicornでは、gunicornの場合にrun_gunicorn管理コマンドを使用しないと、代わりに遅延ロードが行われ、アプリケーションのさまざまな部分からの注文要求に基づいてビットを任意の順序でロードできるため、問題が発生する可能性があります。

すべての問題の根本的な原因は、モジュールのインポートを実行する順序である傾向があります。特に、周期的なモジュールのインポートがある場合はそうです。インポートの欠落も問題になる可能性があります。

ですから、本当の問題があります。追跡するのは難しいですが、モジュールのインポートに特に注意を払ってください。どういうわけか、モデルに関してはかなり多く発生しているようです。

それがあなたの問題であるかどうかは別の質問ですが、そうです、人々は開発サーバーと本番環境の展開の違いを理解しています。

さらに調査するには、実際のエラーメッセージを質問に追加する必要があります。

于 2012-08-29T23:48:59.180 に答える
1

うーん、これは非常に一般的な質問ですが、実稼働環境と開発環境の違いに大きく依存します。私の最初のサーバーの手間から、そして今、私はどういうわけか私自身のルールを手間をかけずに展開する方法を作りました。サーバーへの最初のデプロイ(アプリケーションの最初のデプロイ)を行ったとしても、間違いなく常に何らかの問題が発生します。その後、それは簡単になります。

  1. 開発環境と本番環境では設定を分けておいてください。多くの作業をせずにこれを行う方法については、たくさんの例があります。
  2. Fabric(または他の自動展開)を使用します。サーバーで問題が発生した場合は、ほとんどの場合、次回この問題が発生しないようにfabスクリプトを変更できます。chmodなんらかの方法で、追加のsouth migrate依存関係をインストールするなど。さまざまな環境を処理して、最初にすべてのローカルテストを行うこともできます。
于 2012-08-29T07:41:06.820 に答える