neulab/docprompting-conala huggingface dataset:
Model._state  
The _state attribute refers to a ModelState object that tracks the lifecycle of the model instance. The ModelState object has two attributes: adding, a flag which is True if the model has not been saved to the database yet, and db, a string referring to the database alias the instance was loaded from or saved to. Newly instantiated instances have adding=True and db=None, since they are yet to be saved. Instances fetched from a QuerySet will have adding=False and db set to the alias of the associated database.
Model.objects  
Each non-abstract Model class must have a Manager instance added to it. Django ensures that in your model class you have at least a default Manager specified. If you don’t add your own Manager, Django will add an attribute objects containing default Manager instance. If you add your own Manager instance attribute, the default one does not appear. Consider the following example: from django.db import models

class Person(models.Model):
    # Add manager with another name
    people = models.Manager()
 For more details on model managers see Managers and Retrieving objects.
Model.save(force_insert=False, force_update=False, using=DEFAULT_DB_ALIAS, update_fields=None)
class OneToOneField(to, on_delete, parent_link=False, **options)
OneToOneField.parent_link  
When True and used in a model which inherits from another concrete model, indicates that this field should be used as the link back to the parent class, rather than the extra OneToOneField which would normally be implicitly created by subclassing.
Options.app_label  
If a model is defined outside of an application in INSTALLED_APPS, it must declare which app it belongs to: app_label = 'myapp'
 If you want to represent a model with the format app_label.object_name or app_label.model_name you can use model._meta.label or model._meta.label_lower respectively.
Options.base_manager_name  
The attribute name of the manager, for example, 'objects', to use for the model’s _base_manager.
Options.constraints  
A list of constraints that you want to define on the model: from django.db import models

class Customer(models.Model):
    age = models.IntegerField()

    class Meta:
        constraints = [
            models.CheckConstraint(check=models.Q(age__gte=18), name='age_gte_18'),
        ]
Options.db_table  
The name of the database table to use for the model: db_table = 'music_album'
Options.db_tablespace  
The name of the database tablespace to use for this model. The default is the project’s DEFAULT_TABLESPACE setting, if set. If the backend doesn’t support tablespaces, this option is ignored.
Options.default_manager_name  
The name of the manager to use for the model’s _default_manager.
Options.default_permissions  
Defaults to ('add', 'change', 'delete', 'view'). You may customize this list, for example, by setting this to an empty list if your app doesn’t require any of the default permissions. It must be specified on the model before the model is created by migrate in order to prevent any omitted permissions from being created.
Options.default_related_name  
The name that will be used by default for the relation from a related object back to this one. The default is <model_name>_set. This option also sets related_query_name. As the reverse name for a field should be unique, be careful if you intend to subclass your model. To work around name collisions, part of the name should contain '%(app_label)s' and '%(model_name)s', which are replaced respectively by the name of the application the model is in, and the name of the model, both lowercased. See the paragraph on related names for abstract models.
Options.get_latest_by  
The name of a field or a list of field names in the model, typically DateField, DateTimeField, or IntegerField. This specifies the default field(s) to use in your model Manager’s latest() and earliest() methods. Example: # Latest by ascending order_date.
get_latest_by = "order_date"

# Latest by priority descending, order_date ascending.
get_latest_by = ['-priority', 'order_date']
 See the latest() docs for more.
Options.index_together  
 Use the indexes option instead. The newer indexes option provides more functionality than index_together. index_together may be deprecated in the future.  Sets of field names that, taken together, are indexed: index_together = [
    ["pub_date", "deadline"],
]
 This list of fields will be indexed together (i.e. the appropriate CREATE INDEX statement will be issued.) For convenience, index_together can be a single list when dealing with a single set of fields: index_together = ["pub_date", "deadline"]
Options.indexes  
A list of indexes that you want to define on the model: from django.db import models

class Customer(models.Model):
    first_name = models.CharField(max_length=100)
    last_name = models.CharField(max_length=100)

    class Meta:
        indexes = [
            models.Index(fields=['last_name', 'first_name']),
            models.Index(fields=['first_name'], name='first_name_idx'),
        ]
Options.label  
Representation of the object, returns app_label.object_name, e.g. 'polls.Question'.
Options.label_lower  
Representation of the model, returns app_label.model_name, e.g. 'polls.question'.
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, modification, 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=False. All other aspects of model handling are exactly the same as normal. This includes  Adding an automatic primary key field to the model if you don’t declare it. To avoid confusion for later code readers, it’s recommended to specify all the columns from the database table you are modeling when using unmanaged models.  
If a model with managed=False contains a ManyToManyField that points to another unmanaged model, then the intermediate table for the many-to-many join will also not be created. However, the intermediary table between one managed and one unmanaged model will be created. If you need to change this default behavior, create the intermediary table as an explicit model (with managed set as needed) and use the ManyToManyField.through attribute to make the relation use your custom model.   For tests involving models with managed=False, it’s up to you to ensure the correct tables are created as part of the test setup. If you’re interested in changing the Python-level behavior of a model class, you could use managed=False and create a copy of an existing model. However, there’s a better approach for that situation: Proxy models.
Options.get_field(field_name)  
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 (in order of preference) the related_query_name set by the user, the related_name set by the user, or the name automatically generated by Django. Hidden fields cannot be retrieved by name. If a field with the given name is not found a FieldDoesNotExist exception will be raised. >>> from django.contrib.auth.models import User

# A field on the model
>>> User._meta.get_field('username')
<django.db.models.fields.CharField: username>

# A field from another model that has a relation with the current model
>>> User._meta.get_field('logentry')
<ManyToOneRel: admin.logentry>

# A non existent field
>>> User._meta.get_field('does_not_exist')
Traceback (most recent call last):
    ...
FieldDoesNotExist: User has no field named 'does_not_exist'
Options.get_fields(include_parents=True, include_hidden=False)  
Returns a tuple of fields associated with a model. get_fields() accepts two parameters that can be used to control which fields are returned:  
include_parents  
True by default. Recursively includes fields defined on parent classes. If set to False, get_fields() will only search for fields declared directly on the current model. Fields from models that directly inherit from abstract models or proxy classes are considered to be local, not on the parent. 
include_hidden  
False by default. If set to True, get_fields() will include fields that are used to back other field’s functionality. This will also include any fields that have a related_name (such as ManyToManyField, or ForeignKey) that start with a “+”.  >>> from django.contrib.auth.models import User
>>> User._meta.get_fields()
(<ManyToOneRel: admin.logentry>,
 <django.db.models.fields.AutoField: id>,
 <django.db.models.fields.CharField: password>,
 <django.db.models.fields.DateTimeField: last_login>,
 <django.db.models.fields.BooleanField: is_superuser>,
 <django.db.models.fields.CharField: username>,
 <django.db.models.fields.CharField: first_name>,
 <django.db.models.fields.CharField: last_name>,
 <django.db.models.fields.EmailField: email>,
 <django.db.models.fields.BooleanField: is_staff>,
 <django.db.models.fields.BooleanField: is_active>,
 <django.db.models.fields.DateTimeField: date_joined>,
 <django.db.models.fields.related.ManyToManyField: groups>,
 <django.db.models.fields.related.ManyToManyField: user_permissions>)

# Also include hidden fields.
>>> User._meta.get_fields(include_hidden=True)
(<ManyToOneRel: auth.user_groups>,
 <ManyToOneRel: auth.user_user_permissions>,
 <ManyToOneRel: admin.logentry>,
 <django.db.models.fields.AutoField: id>,
 <django.db.models.fields.CharField: password>,
 <django.db.models.fields.DateTimeField: last_login>,
 <django.db.models.fields.BooleanField: is_superuser>,
 <django.db.models.fields.CharField: username>,
 <django.db.models.fields.CharField: first_name>,
 <django.db.models.fields.CharField: last_name>,
 <django.db.models.fields.EmailField: email>,
 <django.db.models.fields.BooleanField: is_staff>,
 <django.db.models.fields.BooleanField: is_active>,
 <django.db.models.fields.DateTimeField: date_joined>,
 <django.db.models.fields.related.ManyToManyField: groups>,
 <django.db.models.fields.related.ManyToManyField: user_permissions>)
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.ForeignKey(Question, on_delete=models.CASCADE)
    # ...

    class Meta:
        order_with_respect_to = 'question'
 When order_with_respect_to is set, two additional methods are provided to retrieve and to set the order of the related objects: get_RELATED_order() and set_RELATED_order(), where RELATED is the lowercased model name. For example, assuming that a Question object has multiple related Answer objects, the list returned contains the primary keys of the related Answer objects: >>> question = Question.objects.get(id=1)
>>> question.get_answer_order()
[1, 2, 3]
 The order of a Question object’s related Answer objects can be set by passing in a list of Answer primary keys: >>> question.set_answer_order([3, 1, 2])
 The related objects also get two methods, get_next_in_order() and get_previous_in_order(), which can be used to access those objects in their proper order. Assuming the Answer objects are ordered by id: >>> answer = Answer.objects.get(id=2)
>>> answer.get_next_in_order()
<Answer: 3>
>>> answer.get_previous_in_order()
<Answer: 1>
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 and/or query expressions. 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_date']
 To order by pub_date descending, then by author ascending, use this: ordering = ['-pub_date', 'author']
 You can also use query expressions. To order by author ascending and make null values sort last, use this: from django.db.models import F

ordering = [F('author').asc(nulls_last=True)]
Options.permissions  
Extra permissions to enter into the permissions table when creating this object. Add, change, delete, and view 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).
Options.proxy  
If proxy = True, a model which subclasses another model will be treated as a proxy model.
Options.required_db_features  
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.
Options.required_db_vendor  
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.
Options.select_on_save  
Determines if Django will use the pre-1.6 django.db.models.Model.save() algorithm. The old algorithm uses SELECT to determine if there is an existing row to be updated. The new algorithm tries an UPDATE directly. In some rare cases the UPDATE of an existing row isn’t visible to Django. An example is the PostgreSQL ON UPDATE trigger which returns NULL. In such cases the new algorithm will end up doing an INSERT even when a row exists in the database. Usually there is no need to set this attribute. The default is False. See django.db.models.Model.save() for more about the old and new saving algorithm.
Options.unique_together  
 Use UniqueConstraint with the constraints option instead. UniqueConstraint provides more functionality than unique_together. unique_together may be deprecated in the future.  Sets of field names that, taken together, must be unique: unique_together = [['driver', 'restaurant']]
 This is a list of lists that must be unique when considered together. It’s used in the Django admin and is enforced at the database level (i.e., the appropriate UNIQUE statements are included in the CREATE TABLE statement). For convenience, unique_together can be a single list when dealing with a single set of fields: unique_together = ['driver', 'restaurant']
 A ManyToManyField cannot be included in unique_together. (It’s not clear what that would even mean!) If you need to validate uniqueness related to a ManyToManyField, try using a signal or an explicit through model. The ValidationError raised during model validation when the constraint is violated has the unique_together error code.
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.
Options.verbose_name_plural  
The plural name for the object: verbose_name_plural = "stories"
 If this isn’t given, Django will use verbose_name + "s".
output_field  
Defines the type of class returned by the get_lookup() method. It must be a Field instance.
PROTECT  
Prevent deletion of the referenced object by raising ProtectedError, a subclass of django.db.IntegrityError.
class QuerySet(model=None, query=None, using=None, hints=None)  
Usually when you’ll interact with a QuerySet you’ll use it by chaining filters. To make this work, most QuerySet methods return new querysets. These methods are covered in detail later in this section. The QuerySet class has two public attributes you can use for introspection:  
ordered  
True if the QuerySet is ordered — i.e. has an order_by() clause or a default ordering on the model. False otherwise. 
  
db  
The database that will be used if this query is executed now. 
  Note The query parameter to QuerySet exists so that specialized query subclasses can reconstruct internal query state. The value of the parameter is an opaque representation of that query state and is not part of a public API.
datetimes(field_name, kind, order='ASC', tzinfo=None, is_dst=None)
extra(select=None, where=None, params=None, tables=None, order_by=None, select_params=None)
ordered  
True if the QuerySet is ordered — i.e. has an order_by() clause or a default ordering on the model. False otherwise.
select_for_update(nowait=False, skip_locked=False, of=(), no_key=False)
RESTRICT  
Prevent deletion of the referenced object by raising RestrictedError (a subclass of django.db.IntegrityError). Unlike PROTECT, deletion of the referenced object is allowed if it also references a different object that is being deleted in the same operation, but via a CASCADE relationship. Consider this set of models: class Artist(models.Model):
    name = models.CharField(max_length=10)

class Album(models.Model):
    artist = models.ForeignKey(Artist, on_delete=models.CASCADE)

class Song(models.Model):
    artist = models.ForeignKey(Artist, on_delete=models.CASCADE)
    album = models.ForeignKey(Album, on_delete=models.RESTRICT)
 Artist can be deleted even if that implies deleting an Album which is referenced by a Song, because Song also references Artist itself through a cascading relationship. For example: >>> artist_one = Artist.objects.create(name='artist one')
>>> artist_two = Artist.objects.create(name='artist two')
>>> album_one = Album.objects.create(artist=artist_one)
>>> album_two = Album.objects.create(artist=artist_two)
>>> song_one = Song.objects.create(artist=artist_one, album=album_one)
>>> song_two = Song.objects.create(artist=artist_one, album=album_two)
>>> album_one.delete()
# Raises RestrictedError.
>>> artist_two.delete()
# Raises RestrictedError.
>>> artist_one.delete()
(4, {'Song': 2, 'Album': 1, 'Artist': 1})
SET()  
Set the ForeignKey to the value passed to SET(), or if a callable is passed in, the result of calling it. In most cases, passing a callable will be necessary to avoid executing queries at the time your models.py is imported: from django.conf import settings
from django.contrib.auth import get_user_model
from django.db import models

def get_sentinel_user():
    return get_user_model().objects.get_or_create(username='deleted')[0]

class MyModel(models.Model):
    user = models.ForeignKey(
        settings.AUTH_USER_MODEL,
        on_delete=models.SET(get_sentinel_user),
    )
SET_DEFAULT  
Set the ForeignKey to its default value; a default for the ForeignKey must be set.
SET_NULL  
Set the ForeignKey null; this is only possible if null is True.
SlugField.allow_unicode  
If True, the field accepts Unicode letters in addition to ASCII letters. Defaults to False.
class StdDev(expression, output_field=None, sample=False, filter=None, default=None, **extra)  
Returns the standard deviation of the data in the provided expression.  Default alias: <field>__stddev
 Return type: float if input is int, otherwise same as input field, or output_field if supplied  Has one optional argument:  
sample  
By default, StdDev returns the population standard deviation. However, if sample=True, the return value will be the sample standard deviation.
sample  
By default, StdDev returns the population standard deviation. However, if sample=True, the return value will be the sample standard deviation.
class Sum(expression, output_field=None, distinct=False, filter=None, default=None, **extra)  
Computes the sum of all values of the given expression.  Default alias: <field>__sum
 Return type: same as input field, or output_field if supplied  Has one optional argument:  
distinct  
If distinct=True, Sum returns the sum of unique values. This is the SQL equivalent of SUM(DISTINCT <field>). The default value is False.
distinct  
If distinct=True, Sum returns the sum of unique values. This is the SQL equivalent of SUM(DISTINCT <field>). The default value is False.
TextField.db_collation  
 New in Django 3.2.  The database collation name of the field.  Note Collation names are not standardized. As such, this will not be portable across multiple database backends.   Oracle Oracle does not support collations for a TextField.
class TimeField(auto_now=False, auto_now_add=False, **options)
class Transform  
A Transform is a generic class to implement field transformations. A prominent example is __year that transforms a DateField into a IntegerField. The notation to use a Transform in a lookup expression is <expression>__<transformation> (e.g. date__year). This class follows the Query Expression API, which implies that you can use <expression>__<transform1>__<transform2>. It’s a specialized Func() expression that only accepts one argument. It can also be used on the right hand side of a filter or directly as an annotation.  
bilateral  
A boolean indicating whether this transformation should apply to both lhs and rhs. Bilateral transformations will be applied to rhs in the same order as they appear in the lookup expression. By default it is set to False. For example usage, see How to write custom lookups. 
  
lhs  
The left-hand side - what is being transformed. It must follow the Query Expression API. 
  
lookup_name  
The name of the lookup, used for identifying it on parsing query expressions. It cannot contain the string "__". 
  
output_field  
Defines the class this transformation outputs. It must be a Field instance. By default is the same as its lhs.output_field.
bilateral  
A boolean indicating whether this transformation should apply to both lhs and rhs. Bilateral transformations will be applied to rhs in the same order as they appear in the lookup expression. By default it is set to False. For example usage, see How to write custom lookups.
lhs  
The left-hand side - what is being transformed. It must follow the Query Expression API.
lookup_name  
The name of the lookup, used for identifying it on parsing query expressions. It cannot contain the string "__".
output_field  
Defines the class this transformation outputs. It must be a Field instance. By default is the same as its lhs.output_field.
class UniqueConstraint(*expressions, fields=(), name=None, condition=None, deferrable=None, include=None, opclasses=())  
Creates a unique constraint in the database.
class Variance(expression, output_field=None, sample=False, filter=None, default=None, **extra)  
Returns the variance of the data in the provided expression.  Default alias: <field>__variance
 Return type: float if input is int, otherwise same as input field, or output_field if supplied  Has one optional argument:  
sample  
By default, Variance returns the population variance. However, if sample=True, the return value will be the sample variance.
sample  
By default, Variance returns the population variance. However, if sample=True, the return value will be the sample variance.
clean_savepoints(using=None)  
Resets the counter used to generate unique savepoint IDs.
non_atomic_requests(using=None)  
This decorator will negate the effect of ATOMIC_REQUESTS for a given view: from django.db import transaction

@transaction.non_atomic_requests
def my_view(request):
    do_stuff()

@transaction.non_atomic_requests(using='other')
def my_other_view(request):
    do_stuff_on_the_other_database()
 It only works if it’s applied to the view itself.
savepoint(using=None)  
Creates a new savepoint. This marks a point in the transaction that is known to be in a “good” state. Returns the savepoint ID (sid).