Sinyal

Sebuah daftar dari semua sinyal yang Django kirim. Semua sinyal siap-pakai dikirim menggunakan metode send().

Lihat juga

Lihat dokumentasi pada signal dispatcher untuk informasi menurut bagaimana mendaftarkan dan menerima sinyal.

authentication framework mengirim signals when a user is logged in / out.

Sinyal model

Modul django.db.models.signals menentukan sekumpulan sinyal dikirim oleh sistem model.

Peringatan

Signals can make your code harder to maintain. Consider implementing a helper method on a custom manager, to both update your models and perform additional logic, or else overriding model methods before using model signals.

Peringatan

Banyak dari sinyal-sinyal ini dikirim oleh beragam metode model seperti __init__() atau save() yang anda dapat timpa dalam kode anda sendiri.

If you override these methods on your model, you must call the parent class' methods for these signals to be sent.

Note also that Django stores signal handlers as weak references by default, so if your handler is a local function, it may be garbage collected. To prevent this, pass weak=False when you call the signal's connect().

Catatan

Model signals sender model can be lazily referenced when connecting a receiver by specifying its full application label. For example, an Question model defined in the polls application could be referenced as 'polls.Question'. This sort of reference can be quite handy when dealing with circular import dependencies and swappable models.

pre_init

django.db.models.signals.pre_init

Whenever you instantiate a Django model, this signal is sent at the beginning of the model's __init__() method.

Argumen dikirim dengan dinyal ini:

sender

Kelas model yang baru mempunyai sebuah instance yang dibuat.

args

A list of positional arguments passed to __init__().

kwargs

A dictionary of keyword arguments passed to __init__().

For example, the tutorial has this line:

q = Question(question_text="What's new?", pub_date=timezone.now())

Argumen dikirim ke penangan pre_init akan berupa:

Argument	Nilai
sender	Question (the class itself)
args	[] (an empty list because there were no positional arguments passed to __init__())
kwargs	{'question_text': "What's new?", 'pub_date': datetime.datetime(2012, 2, 26, 13, 0, 0, 775217, tzinfo=datetime.UTC)}

post_init

django.db.models.signals.post_init

Seperti pre_init, tetapi satu ini dikirim ketika metode __init__() selesai.

Argumen dikirim dengan dinyal ini:

sender

Seperti diatas, kelas model yang baru mempunyai sebuah instance dibuat.

instance

Instance sebenarnya dari model yang baru saja dibuat.

Catatan

instance._state isn't set before sending the post_init signal, so _state attributes always have their default values. For example, _state.db is None.

Peringatan

For performance reasons, you shouldn't perform queries in receivers of pre_init or post_init signals because they would be executed for each instance returned during queryset iteration.

pre_save

django.db.models.signals.pre_save

Ini dikirim pada awal dari metode save() model.

Argumen dikirim dengan dinyal ini:

sender

Kelas model.

instance

Instance sebenarnya sedang disimpan.

raw

A boolean; True if the model is saved exactly as presented (i.e. when loading a fixture). One should not query/modify other records in the database as the database might not be in a consistent state yet.

menggunakan

Nama lain basisdata sedang digunakan.

update_fields

Kumpulan dari bidang untuk memperbaharui seperti dilewatkan ke Model.save(), atau None jika update_fields tidak dilewatkan ke save().

post_save

django.db.models.signals.post_save

Seperti pre_save, tetapi dikirim pada akhir dari metode save().

Argumen dikirim dengan dinyal ini:

sender

Kelas model.

instance

Instance sebenarnya sedang disimpan.

created

Boolean; True jika sebuah rekaman baru telah dibuat.

raw

A boolean; True if the model is saved exactly as presented (i.e. when loading a fixture). One should not query/modify other records in the database as the database might not be in a consistent state yet.

menggunakan

Nama lain basisdata sedang digunakan.

update_fields

Kumpulan dari bidang untuk memperbaharui seperti dilewatkan ke Model.save(), atau None jika update_fields tidak dilewatkan ke save().

pre_delete

django.db.models.signals.pre_delete

Dikirim pada awal dari metode delete() model dan metode delete() queryset.

Argumen dikirim dengan dinyal ini:

sender

Kelas model.

instance

Instance sebenarnya sedang dihapus.

menggunakan

Nama lain basisdata sedang digunakan.

origin

The Model or QuerySet instance from which the deletion originated, that is, the instance whose delete() method was invoked.

post_delete

django.db.models.signals.post_delete

Like pre_delete, but sent at the end of a model's delete() method and a queryset's delete() method.

Argumen dikirim dengan dinyal ini:

sender

Kelas model.

instance

Instance sebenarnya sedang dihapus.

Catat bahwa obyek tidak akan lagi berada dalam basisdata, jadi waspadalah apa yang anda lakukan dengan contoh ini.

menggunakan

Nama lain basisdata sedang digunakan.

origin

The Model or QuerySet instance from which the deletion originated, that is, the instance whose delete() method was invoked.

m2m_changed

django.db.models.signals.m2m_changed

Dikirim ketika a ManyToManyField dirubah pada instance model. Berbicara dengan ketat, ini bukan sebuah sinyal model karena itu dikirim oleh ManyToManyField, tetapi sejak itu melengkapi pre_save/post_save dan pre_delete/post_delete ketika itu datang untuk melacak perubahan pada model, itu disertakan disini.

Argumen dikirim dengan dinyal ini:

sender

The intermediate model class describing the ManyToManyField. This class is automatically created when a many-to-many field is defined; you can access it using the through attribute on the many-to-many field.

instance

The instance whose many-to-many relation is updated. This can be an instance of the sender, or of the class the ManyToManyField is related to.

action

Sebuah string menunjukkan jenis dari pembaharuan yang selesai pada hubungan. Ini dapat berupa satu dari berikut:

"pre_add"

Dikirim sebelum satu atau lebih obyek ditambahkan ke hubungan.

"post_add"

Dikirim setelah satu atau lebih obyek ditambahkan pada hubungan.

"pre_remove"

Dikirim sebelum satu atau lebih obyek dipindahkan dari hubungan.

"post_remove"

Dikirim setelah satu atau lebih obyek dipindahkan dari hubungan.

"pre_clear"

Dikirim sebelum hubungan dibersihkan.

"post_clear"

Dikirim*setelah* hubungan dibersihkan.

reverse

Indicates which side of the relation is updated (i.e., if it is the forward or reverse relation that is being modified).

model

Kelas dari obyek-byek yang ditambahkan juga, dipindahkan dari atau dibersihkan dari hubungan.

pk_set

For the pre_add and post_add actions, this is a set of primary key values that will be, or have been, added to the relation. This may be a subset of the values submitted to be added, since inserts must filter existing values in order to avoid a database IntegrityError.

For the pre_remove and post_remove actions, this is a set of primary key values that was submitted to be removed from the relation. This is not dependent on whether the values actually will be, or have been, removed. In particular, non-existent values may be submitted, and will appear in pk_set, even though they have no effect on the database.

Untuk tindakan pre_clear dan post_clear, ini adalah None.

menggunakan

Nama lain basisdata sedang digunakan.

Sebagai contoh, jika sebuah Pizza dapat memiliki banyak obyek Topping, dimodelkan seperti ini:

class Topping(models.Model):
    # ...
    pass


class Pizza(models.Model):
    # ...
    toppings = models.ManyToManyField(Topping)

Jika kami menghubungkan penangan seperti ini:

from django.db.models.signals import m2m_changed


def toppings_changed(sender, **kwargs):
    # Do something
    pass


m2m_changed.connect(toppings_changed, sender=Pizza.toppings.through)

and then did something like this:

>>> p = Pizza.objects.create(...)
>>> t = Topping.objects.create(...)
>>> p.toppings.add(t)

argumen-argumen dikirim ke penangan m2m_changed (toppings_changed dalam contoh diatas) akan menjadi:

Argument	Nilai
sender	Pizza.toppings.through (kelas m2m menengah)
instance	p (instance``Pizza`` sedang dirubah)
action	"pre_add" (diikuti oleh sinyal terpisah dengan "post_add")
reverse	False (Pizza contains the ManyToManyField, so this call modifies the forward relation)
model	Topping (kelas dari obyek ditambahkan pada Pizza)
pk_set	{t.id} (sejak hanya Topping t yang ditambahkan ke hubungan)
menggunakan	"default" (sejak kiriman perute awalan ditulis disini)

And if we would then do something like this:

>>> t.pizza_set.remove(p)

argumen dikirim ke penangan m2m_changed akan berupa:

Argument	Nilai
sender	Pizza.toppings.through (kelas m2m menengah)
instance	t (instance Topping sedang dirubah)
action	"pre_remove" (diikuti oleh sinyal terpisah dengan "post_remove")
reverse	True (Pizza mengandung ManyToManyField, jadi panggilan ini merubah hubungan kebalikan)
model	Pizza (kelas dari obyek dipindahkan dari Topping)
pk_set	{p.id} (sejak hanya Pizza p telah dipindahkan dari hubungan)
menggunakan	"default" (sejak kiriman perute awalan ditulis disini)

class_prepared

django.db.models.signals.class_prepared

Sent whenever a model class has been "prepared" -- that is, once a model has been defined and registered with Django's model system. Django uses this signal internally; it's not generally used in third-party applications.

Sejak sinyal ini dikirim selama pengolahan pengumpulan registrar aplikasi, dan AppConfig.ready() berjalan setelah registrar sepenuhnya dikumpulkan, penerima tidak dapat dihubungkan di metode itu. Satu kemungkinan adalah menghubungkan mereka AppConfig.__init__() sebagai gantinya, merawat tidak untuk mengimpor model atau panggilan pemicu pada registrar aplikasi.

Argumen-argumen yang dikirim dengan sinyal ini:

sender

Kelas model yang telah dipersiapkan.

Pengelolaan sinyal

Sinyal dikirim oleh django-admin.

pre_migrate

django.db.models.signals.pre_migrate

Sent by the migrate command before it starts to install an application. It's not emitted for applications that lack a models module.

Argumen dikirim dengan dinyal ini:

sender

Sebuah instance AppConfig untuk aplikasi tentang untuk dipindahkan/disinkronisasikan.

app_config

Sama seperti sender.

verbosity

Indicates how much information manage.py is printing on screen. See the --verbosity flag for details.

Fungsi-fungsi yang mendengarkan untuk pre_migrate harus menyesuaikan apa mereka keluarkan ke layar berdasarkan pada nilai dari argumen ini.

interactive

If interactive is True, it's safe to prompt the user to input things on the command line. If interactive is False, functions which listen for this signal should not try to prompt for anything.

Sebagai contoh, aplikasi django.contrib.auth hanya menunjuk untuk membuat pengguna super ketika interactive adalah True.

stdout

A stream-like object where verbose output should be redirected.

menggunakan

Nama lain dari basisdata dimana sebuah perintah akan beroperasi.

plan

The migration plan that is going to be used for the migration run. While the plan is not public API, this allows for the rare cases when it is necessary to know the plan. A plan is a list of 2-tuples with the first item being the instance of a migration class and the second item showing if the migration was rolled back (True) or applied (False).

apps

Sebuah instance dari Apps mengandung keadaan dari proyek sebelum perpindahan berjalan. Itu harus digunakan sebagai gantinya dari registrar apps global untuk mengambil model yang anda ingin lakukan tindakan.

post_migrate

django.db.models.signals.post_migrate

Dikirim pada akhir dari migrate (bahkan jika tidak ada perpindahan dijalankan) dan perintah flush. Itu tidak dikeluarkan untuk aplikasi yang kekurangan modeul models.

Handlers of this signal must not perform database schema alterations as doing so may cause the flush command to fail if it runs during the migrate command.

Argumen dikirim dengan dinyal ini:

sender

Instance AppConfig untuk aplikasi yang telah dipasang.

app_config

Sama seperti sender.

verbosity

Indicates how much information manage.py is printing on screen. See the --verbosity flag for details.

Fungsi-fungsi yang mendengarkan untuk post_migrate harus menyesuaikan apa mereka keluarkan ke layar berdasarkan pada nilai dari argumen ini.

interactive

If interactive is True, it's safe to prompt the user to input things on the command line. If interactive is False, functions which listen for this signal should not try to prompt for anything.

Sebagai contoh, aplikasi django.contrib.auth hanya menunjuk untuk membuat pengguna super ketika interactive adalah True.

stdout

A stream-like object where verbose output should be redirected.

menggunakan

Nama lain basisdata digunakan untuk sinkronisasi. Awalan pada basisdata default.

plan

The migration plan that was used for the migration run. While the plan is not public API, this allows for the rare cases when it is necessary to know the plan. A plan is a list of 2-tuples with the first item being the instance of a migration class and the second item showing if the migration was rolled back (True) or applied (False).

apps

Sebuah instance dari Apps mengandung keadaan dari proyek setelah perpindahan berjalan. Itu harus digunakan sebagai gantinya dari registrar apps global untuk mengambil model yang anda ingin lakukan tindakan.

Sebagai contoh, anda dapat mendaftarkan sebuah callback dalam sebuah AppConfig seperti ini:

from django.apps import AppConfig
from django.db.models.signals import post_migrate


def my_callback(sender, **kwargs):
    # Your specific logic here
    pass


class MyAppConfig(AppConfig):
    ...

    def ready(self):
        post_migrate.connect(my_callback, sender=self)

Catatan

If you provide an AppConfig instance as the sender argument, please ensure that the signal is registered in ready(). AppConfigs are recreated for tests that run with a modified set of INSTALLED_APPS (such as when settings are overridden) and such signals should be connected for each new AppConfig instance.

Sinyal permintaan/tanggapan

Sinyal dikirim oleh kerangka kerja inti ketika mengolah sebuah permintaan.

Peringatan

Signals can make your code harder to maintain. Consider using a middleware before using request/response signals.

request_started

django.core.signals.request_started

Dikirim ketika Django mulai mengolah sebuah permintaan HTTP.

Argumen dikirim dengan dinyal ini:

sender

Kelas penangan -- misalnya django.core.handlers.wsgi.WsgiHandler -- yang menangani permintaan.

environ

Dictionary environ disediakan pada permintaan.

request_finished

django.core.signals.request_finished

Dikirim ketika Django selesai mengirimkan sebuah tanggapan HTTP ke klien.

Argumen dikirim dengan dinyal ini:

sender

Kelas penangan, seperti diatas.

got_request_exception

django.core.signals.got_request_exception

Sinyal ini dikirim ketika Django menghadapi sebuah pengecualian selagi mengolah sebuah permintaan HTTP yang datang.

Argumen dikirim dengan dinyal ini:

sender

Tidak digunakan (selalu None).

request

Obyek HttpRequest

Sinyal percobaan

Sinyal hanya dikirim ketika running tests.

setting_changed

django.test.signals.setting_changed

Sinyal dikirim ketika nilai dari pengaturan berubah melalui pengelola konteks django.test.TestCase.settings() atau pengelola penghias/konteks django.test.override_settings().

It's actually sent twice: when the new value is applied ("setup") and when the original value is restored ("teardown"). Use the enter argument to distinguish between the two.

Anda dapat juga mengimpor sinyal dari django.core.signals untuk menghindari impor dari django.test dalam keadaan bukan-percobaan.

Argumen dikirim dengan dinyal ini:

sender

Penangan percobaan.

setting

Nama dari pengaturan.

value

Nilai dari pengaturan setelah berubah. Untuk pengaturan yang awalnya tidak ada, dalam fase "teardown", value adalah None.

enter

Boolean; True jika pengaturan diberlakukan, False jika disimpan kembali.

template_rendered

django.test.signals.template_rendered

Dikirim ketika sistem percobaan membangun sebuah cetakan. Siyal ini tidak dikeluarkan selama tindakan biasa dari peladen Django -- itu hanya tersedia selama percobaan.

Argumen dikirim dengan dinyal ini:

sender

Obyek Template yang dibangun.

template

Sama seperti pengirim

context

Context dimana cetakan dibangun.

Pembungkus Basisdata

Sinyal dikirim oleh pembungkus basisdata ketika hubungan basisdata dimulai.

connection_created

django.db.backends.signals.connection_created

Sent when the database wrapper makes the initial connection to the database. This is particularly useful if you'd like to send any post connection commands to the SQL backend.

Argumen dikirim dengan dinyal ini:

sender

Kelas pembungkus basisdata -- yaitu. django.db.backends.postgresql.DatabaseWrapper atau django.db.backends.mysql.DatabaseWrapper, dll.

connection

The database connection that was opened. This can be used in a multiple-database configuration to differentiate connection signals from different databases.

Tasks signals

New in Django 6.0.

Signals sent by the tasks framework.

task_enqueued

django.tasks.signals.task_enqueued

Sent once a Task has been enqueued.

Argumen dikirim dengan dinyal ini:

sender

The backend class which the Task was enqueued on to.

task_result

The enqueued TaskResult.

task_started

django.tasks.signals.task_started

Sent when a Task has started executing.

Argumen dikirim dengan dinyal ini:

sender

The backend class which the Task was enqueued on to.

task_result

The started TaskResult.

task_finished

django.tasks.signals.task_finished

Sent once a Task has finished executing, successfully or otherwise.

Argumen dikirim dengan dinyal ini:

sender

The backend class which the Task was enqueued on to.

task_result

The finished TaskResult.