dispatch.Signal

class Signal(providing_args=list) [source] All signals are django.dispatch.Signal instances. The providing_args is a list of the names of arguments the signal will provide to listeners. This is purely documentational, however, as there is nothing that checks that the signal actually provides these arguments to its listeners. For example: import django.dispatch pizza_done = django.dispatch.Signal(providing_args=["toppings", "size"]) This declares a pizza_done signal that will provide receiv

dispatch.receiver()

receiver(signal) [source] Parameters: signal – A signal or a list of signals to connect a function to. Here’s how you connect with the decorator: from django.core.signals import request_finished from django.dispatch import receiver @receiver(request_finished) def my_callback(sender, **kwargs): print("Request finished!") Now, our my_callback function will be called each time a request finishes. Where should this code live? Strictly speaking, signal handling and registration code can

Deployment checklist

The Internet is a hostile environment. Before deploying your Django project, you should take some time to review your settings, with security, performance, and operations in mind. Django includes many security features. Some are built-in and always enabled. Others are optional because they aren’t always appropriate, or because they’re inconvenient for development. For example, forcing HTTPS may not be suitable for all websites, and it’s impractical for local development. Performance optimizatio

Deploying static files

See also For an introduction to the use of django.contrib.staticfiles, see Managing static files (e.g. images, JavaScript, CSS). Serving static files in production The basic outline of putting static files into production is simple: run the collectstatic command when static files change, then arrange for the collected static files directory (STATIC_ROOT) to be moved to the static file server and served. Depending on STATICFILES_STORAGE, files may need to be moved to a new location manually or

Deploying GeoDjango

Basically, the deployment of a GeoDjango application is not different from the deployment of a normal Django application. Please consult Django’s deployment documentation. Warning GeoDjango uses the GDAL geospatial library which is not thread safe at this time. Thus, it is highly recommended to not use threading when deploying – in other words, use an appropriate configuration of Apache. For example, when configuring your application with mod_wsgi, set the WSGIDaemonProcess attribute threads t

Deploying Django

Django’s chock-full of shortcuts to make Web developer’s lives easier, but all those tools are of no use if you can’t easily deploy your sites. Since Django’s inception, ease of deployment has been a major goal. How to deploy with WSGI Deployment checklist If you’re new to deploying Django and/or Python, we’d recommend you try mod_wsgi first. In most cases it’ll be the easiest, fastest, and most stable deployment choice.

db.transaction.set_rollback()

set_rollback(rollback, using=None) [source] Setting the rollback flag to True forces a rollback when exiting the innermost atomic block. This may be useful to trigger a rollback without raising an exception. Setting it to False prevents such a rollback. Before doing that, make sure you’ve rolled back the transaction to a known-good savepoint within the current atomic block! Otherwise you’re breaking atomicity and data corruption may occur.

db.transaction.set_autocommit()

set_autocommit(autocommit, using=None) [source] These functions take a using argument which should be the name of a database. If it isn’t provided, Django uses the "default" database. Autocommit is initially turned on. If you turn it off, it’s your responsibility to restore it. Once you turn autocommit off, you get the default behavior of your database adapter, and Django won’t help you. Although that behavior is specified in PEP 249, implementations of adapters aren’t always consistent with

db.transaction.savepoint_rollback()

savepoint_rollback(sid, using=None) [source] Rolls back the transaction to savepoint sid. These functions do nothing if savepoints aren’t supported or if the database is in autocommit mode. In addition, there’s a utility function:

db.transaction.savepoint_commit()

savepoint_commit(sid, using=None) [source] Releases savepoint sid. The changes performed since the savepoint was created become part of the transaction.