3

次のようなハンドラーmyapp/management/__init__.pyを登録している があります。post_syncdb

from django.db.models import signals
from features import models as features

def create_features(app, created_models, verbosity, **kwargs):
    print "Creating features!"
    # Do stuff...

signals.post_syncdb.connect(create_features, sender=features)

以下のことを確認しました。

  1. featuresとの両方myappが入っているsettings.INSTALLED_APPS
  2. myapp.managementsyncdb が実行される前にロードされます (モジュール レベルで print ステートメントを介して確認されます)。
  3. featuresアプリは によって処理されておりsyncdb、post_syncdb信号を発信しています (syncdbの出力を--verbosity=2.
  4. 別のアプリのペアにまったく同じイディオムを使用していますが、そのハンドラーは正しく呼び出されます。2 つのモジュールを比較しましたが、呼び出し間に関連する違いは見つかりませんでした。

ただし、myapp.management.create_features呼び出されることはありません。私は何が欠けていますか？

4

3 に答える 3

3

models.py に入れてみてください

于 2010-12-09T00:49:18.097 に答える
1

同じ問題に遭遇しました。私がそれを解決した方法はsender、関数の引数からを削除し、コールバック関数内でそれをチェックすることでした。

from django.db.models import signals
from features import models as features

def create_features(app, created_models, verbosity, **kwargs):
    print "Creating features!"
    if app != features #this will work as it compares models module instances
        return
    # Do stuff...

signals.post_syncdb.connect(create_features)

そうすれば、Django docs が示唆するように、それらを管理モジュールに保持できます。あなたが提案したように動作することに同意します。おそらく、 の Signal クラスの実装を掘り下げることができdjango.dispatchます。

于 2011-11-10T11:24:13.217 に答える
0

ポイントは にありsenderます。カスタム コールバックは、senderうまくいった場合にのみ呼び出されます。私の場合、syncdb が初めて呼び出されたのではなく、同期されたモデルがデータベースに存在する場合はうまくいきませんsender。db.modelsドキュメントには書かれていますが、適切に強調されていません。

差出人

インストールされたばかりのモデル モジュール。つまり、syncdb が "foo.bar.myapp" というアプリをインストールした場合、送信者は foo.bar.myapp.models モジュールになります。

したがって、私の解決策は、データベースを削除して、アプリを再度インストールすることでした。

于 2011-10-20T14:53:01.487 に答える