db.models.Options.verbose_name

Options.verbose_name A human-readable name for the object, singular: verbose_name = "pizza" If this isn’t given, Django will use a munged version of the class name: CamelCase becomes camel case.

db.models.Options.required_db_vendor

Options.required_db_vendor New in Django 1.9. Name of a supported database vendor that this model is specific to. Current built-in vendor names are: sqlite, postgresql, mysql, oracle. If this attribute is not empty and the current connection vendor doesn’t match it, the model will not be synchronized.

db.models.Options.order_with_respect_to

Options.order_with_respect_to Makes this object orderable with respect to the given field, usually a ForeignKey. This can be used to make related objects orderable with respect to a parent object. For example, if an Answer relates to a Question object, and a question has more than one answer, and the order of answers matters, you’d do this: from django.db import models class Question(models.Model): text = models.TextField() # ... class Answer(models.Model): question = models.Fo

db.models.Options.required_db_features

Options.required_db_features New in Django 1.9. List of database features that the current connection should have so that the model is considered during the migration phase. For example, if you set this list to ['gis_enabled'], the model will only be synchronized on GIS-enabled databases. It’s also useful to skip some models when testing with several database backends. Avoid relations between models that may or may not be created as the ORM doesn’t handle this.

db.models.Options.permissions

Options.permissions Extra permissions to enter into the permissions table when creating this object. Add, delete and change permissions are automatically created for each model. This example specifies an extra permission, can_deliver_pizzas: permissions = (("can_deliver_pizzas", "Can deliver pizzas"),) This is a list or tuple of 2-tuples in the format (permission_code, human_readable_permission_name).

db.models.Options.ordering

Options.ordering The default ordering for the object, for use when obtaining lists of objects: ordering = ['-order_date'] This is a tuple or list of strings. Each string is a field name with an optional “-” prefix, which indicates descending order. Fields without a leading “-” will be ordered ascending. Use the string ”?” to order randomly. For example, to order by a pub_date field ascending, use this: ordering = ['pub_date'] To order by pub_date descending, use this: ordering = ['-pub_dat

db.models.Options.proxy

Options.proxy If proxy = True, a model which subclasses another model will be treated as a proxy model.

db.models.Options.label_lower

Options.label_lower New in Django 1.9. Representation of the model, returns app_label.model_name, e.g. 'polls.question'.

db.models.options.Options.get_field()

Options.get_field(field_name) [source] Returns the field instance given a name of a field. field_name can be the name of a field on the model, a field on an abstract or inherited model, or a field defined on another model that points to the model. In the latter case, the field_name will be the related_name defined by the user or the name automatically generated by Django itself. Hidden fields cannot be retrieved by name. If a field with the given name is not found a FieldDoesNotExist excepti

db.models.Options.managed

Options.managed Defaults to True, meaning Django will create the appropriate database tables in migrate or as part of migrations and remove them as part of a flush management command. That is, Django manages the database tables’ lifecycles. If False, no database table creation or deletion operations will be performed for this model. This is useful if the model represents an existing table or a database view that has been created by some other means. This is the only difference when managed=F