db.migrations.operations.CreateModel

class CreateModel(name, fields, options=None, bases=None, managers=None) [source] Creates a new model in the project history and a corresponding table in the database to match it. name is the model name, as would be written in the models.py file. fields is a list of 2-tuples of (field_name, field_instance). The field instance should be an unbound field (so just models.CharField(...), rather than a field taken from another model). options is an optional dictionary of values from the model’s M

gis.geos.GEOSGeometry.sym_difference()

GEOSGeometry.sym_difference(other) Returns a GEOSGeometry combining the points in this geometry not in other, and the points in other not in this geometry.

db.models.TextField

class TextField(**options) [source] A large text field. The default form widget for this field is a Textarea. If you specify a max_length attribute, it will be reflected in the Textarea widget of the auto-generated form field. However it is not enforced at the model or database level. Use a CharField for that. MySQL users If you are using this field with MySQLdb 1.2.1p2 and the utf8_bin collation (which is not the default), there are some issues to be aware of. Refer to the MySQL database n

views.static.serve()

static.serve(request, path, document_root, show_indexes=False) There may be files other than your project’s static assets that, for convenience, you’d like to have Django serve for you in local development. The serve() view can be used to serve any directory you give it. (This view is not hardened for production use and should be used only as a development aid; you should serve these files in production using a real front-end web server). The most likely example is user-uploaded content in M

utils.timezone.make_aware()

make_aware(value, timezone=None, is_dst=None) [source] Returns an aware datetime that represents the same point in time as value in timezone, value being a naive datetime. If timezone is set to None, it defaults to the current time zone. When pytz is installed, the exception pytz.AmbiguousTimeError will be raised if you try to make value aware during a DST transition where the same time occurs twice (when reverting from DST). Setting is_dst to True or False will avoid the exception by choosi

PostgreSQL specific lookups

Trigram similarity New in Django 1.10. The trigram_similar lookup allows you to perform trigram lookups, measuring the number of trigrams (three consecutive characters) shared, using a dedicated PostgreSQL extension. A trigram lookup is given an expression and returns results that have a similarity measurement greater than the current similarity threshold. To use it, add 'django.contrib.postgres' in your INSTALLED_APPS and activate the pg_trgm extension on PostgreSQL. You can install the exte

views.generic.list.MultipleObjectTemplateResponseMixin.get_template_names()

get_template_names() Returns a list of candidate template names. Returns the following list: the value of template_name on the view (if provided) <app_label>/<model_name><template_name_suffix>.html

postgres.fields.DateRangeField

class DateRangeField(**options) [source] Stores a range of dates. Based on a DateField. Represented by a daterange in the database and a DateRange in Python. Regardless of the bounds specified when saving the data, PostgreSQL always returns a range in a canonical form that includes the lower bound and excludes the upper bound; that is [).

test.TransactionTestCase

class TransactionTestCase [source] TransactionTestCase inherits from SimpleTestCase to add some database-specific features: Resetting the database to a known state at the beginning of each test to ease testing and using the ORM. Database fixtures. Test skipping based on database backend features. The remaining specialized assert* methods. Django’s TestCase class is a more commonly used subclass of TransactionTestCase that makes use of database transaction facilities to speed up the process

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