neulab/docprompting-conala huggingface dataset:
ForeignKey.db_constraint  
Controls whether or not a constraint should be created in the database for this foreign key. The default is True, and that’s almost certainly what you want; setting this to False can be very bad for data integrity. That said, here are some scenarios where you might want to do this:  You have legacy data that is not valid. You’re sharding your database.  If this is set to False, accessing a related object that doesn’t exist will raise its DoesNotExist exception.
ForeignKey.limit_choices_to  
Sets a limit to the available choices for this field when this field is rendered using a ModelForm or the admin (by default, all objects in the queryset are available to choose). Either a dictionary, a Q object, or a callable returning a dictionary or Q object can be used. For example: staff_member = models.ForeignKey(
    User,
    on_delete=models.CASCADE,
    limit_choices_to={'is_staff': True},
)
 causes the corresponding field on the ModelForm to list only Users that have is_staff=True. This may be helpful in the Django admin. The callable form can be helpful, for instance, when used in conjunction with the Python datetime module to limit selections by date range. For example: def limit_pub_date_choices():
    return {'pub_date__lte': datetime.date.today()}

limit_choices_to = limit_pub_date_choices
 If limit_choices_to is or returns a Q object, which is useful for complex queries, then it will only have an effect on the choices available in the admin when the field is not listed in raw_id_fields in the ModelAdmin for the model.  Note If a callable is used for limit_choices_to, it will be invoked every time a new form is instantiated. It may also be invoked when a model is validated, for example by management commands or the admin. The admin constructs querysets to validate its form inputs in various edge cases multiple times, so there is a possibility your callable may be invoked several times.
ForeignKey.on_delete  
When an object referenced by a ForeignKey is deleted, Django will emulate the behavior of the SQL constraint specified by the on_delete argument. For example, if you have a nullable ForeignKey and you want it to be set null when the referenced object is deleted: user = models.ForeignKey(
    User,
    models.SET_NULL,
    blank=True,
    null=True,
)
 on_delete doesn’t create an SQL constraint in the database. Support for database-level cascade options may be implemented later.
ForeignKey.related_name  
The name to use for the relation from the related object back to this one. It’s also the default value for related_query_name (the name to use for the reverse filter name from the target model). See the related objects documentation for a full explanation and example. Note that you must set this value when defining relations on abstract models; and when you do so some special syntax is available. If you’d prefer Django not to create a backwards relation, set related_name to '+' or end it with '+'. For example, this will ensure that the User model won’t have a backwards relation to this model: user = models.ForeignKey(
    User,
    on_delete=models.CASCADE,
    related_name='+',
)
ForeignKey.related_query_name  
The name to use for the reverse filter name from the target model. It defaults to the value of related_name or default_related_name if set, otherwise it defaults to the name of the model: # Declare the ForeignKey with related_query_name
class Tag(models.Model):
    article = models.ForeignKey(
        Article,
        on_delete=models.CASCADE,
        related_name="tags",
        related_query_name="tag",
    )
    name = models.CharField(max_length=255)

# That's now the name of the reverse filter
Article.objects.filter(tag__name="important")
 Like related_name, related_query_name supports app label and class interpolation via some special syntax.
ForeignKey.swappable  
Controls the migration framework’s reaction if this ForeignKey is pointing at a swappable model. If it is True - the default - then if the ForeignKey is pointing at a model which matches the current value of settings.AUTH_USER_MODEL (or another swappable model setting) the relationship will be stored in the migration using a reference to the setting, not to the model directly. You only want to override this to be False if you are sure your model should always point toward the swapped-in model - for example, if it is a profile model designed specifically for your custom user model. Setting it to False does not mean you can reference a swappable model even if it is swapped out - False means that the migrations made with this ForeignKey will always reference the exact model you specify (so it will fail hard if the user tries to run with a User model you don’t support, for example). If in doubt, leave it to its default of True.
ForeignKey.to_field  
The field on the related object that the relation is to. By default, Django uses the primary key of the related object. If you reference a different field, that field must have unique=True.
class Func(*expressions, **extra)  
 
function  
A class attribute describing the function that will be generated. Specifically, the function will be interpolated as the function placeholder within template. Defaults to None. 
  
template  
A class attribute, as a format string, that describes the SQL that is generated for this function. Defaults to '%(function)s(%(expressions)s)'. If you’re constructing SQL like strftime('%W', 'date') and need a literal % character in the query, quadruple it (%%%%) in the template attribute because the string is interpolated twice: once during the template interpolation in as_sql() and once in the SQL interpolation with the query parameters in the database cursor. 
  
arg_joiner  
A class attribute that denotes the character used to join the list of expressions together. Defaults to ', '. 
  
arity  
A class attribute that denotes the number of arguments the function accepts. If this attribute is set and the function is called with a different number of expressions, TypeError will be raised. Defaults to None. 
  
as_sql(compiler, connection, function=None, template=None, arg_joiner=None, **extra_context)  
Generates the SQL fragment for the database function. Returns a tuple (sql, params), where sql is the SQL string, and params is the list or tuple of query parameters. The as_vendor() methods should use the function, template, arg_joiner, and any other **extra_context parameters to customize the SQL as needed. For example:  django/db/models/functions.py class ConcatPair(Func):
    ...
    function = 'CONCAT'
    ...

    def as_mysql(self, compiler, connection, **extra_context):
        return super().as_sql(
            compiler, connection,
            function='CONCAT_WS',
            template="%(function)s('', %(expressions)s)",
            **extra_context
        )
  To avoid an SQL injection vulnerability, extra_context must not contain untrusted user input as these values are interpolated into the SQL string rather than passed as query parameters, where the database driver would escape them.
arg_joiner  
A class attribute that denotes the character used to join the list of expressions together. Defaults to ', '.
arity  
A class attribute that denotes the number of arguments the function accepts. If this attribute is set and the function is called with a different number of expressions, TypeError will be raised. Defaults to None.
as_sql(compiler, connection, function=None, template=None, arg_joiner=None, **extra_context)  
Generates the SQL fragment for the database function. Returns a tuple (sql, params), where sql is the SQL string, and params is the list or tuple of query parameters. The as_vendor() methods should use the function, template, arg_joiner, and any other **extra_context parameters to customize the SQL as needed. For example:  django/db/models/functions.py class ConcatPair(Func):
    ...
    function = 'CONCAT'
    ...

    def as_mysql(self, compiler, connection, **extra_context):
        return super().as_sql(
            compiler, connection,
            function='CONCAT_WS',
            template="%(function)s('', %(expressions)s)",
            **extra_context
        )
  To avoid an SQL injection vulnerability, extra_context must not contain untrusted user input as these values are interpolated into the SQL string rather than passed as query parameters, where the database driver would escape them.
function  
A class attribute describing the function that will be generated. Specifically, the function will be interpolated as the function placeholder within template. Defaults to None.
template  
A class attribute, as a format string, that describes the SQL that is generated for this function. Defaults to '%(function)s(%(expressions)s)'. If you’re constructing SQL like strftime('%W', 'date') and need a literal % character in the query, quadruple it (%%%%) in the template attribute because the string is interpolated twice: once during the template interpolation in as_sql() and once in the SQL interpolation with the query parameters in the database cursor.
class ExtractDay(expression, tzinfo=None, **extra)  
 
lookup_name = 'day'
class ExtractHour(expression, tzinfo=None, **extra)  
 
lookup_name = 'hour'
class ExtractIsoWeekDay(expression, tzinfo=None, **extra)  
Returns the ISO-8601 week day with day 1 being Monday and day 7 being Sunday.  
lookup_name = 'iso_week_day'
class ExtractIsoYear(expression, tzinfo=None, **extra)  
Returns the ISO-8601 week-numbering year.  
lookup_name = 'iso_year'
class ExtractMinute(expression, tzinfo=None, **extra)  
 
lookup_name = 'minute'
class ExtractMonth(expression, tzinfo=None, **extra)  
 
lookup_name = 'month'
class ExtractQuarter(expression, tzinfo=None, **extra)  
 
lookup_name = 'quarter'
class ExtractSecond(expression, tzinfo=None, **extra)  
 
lookup_name = 'second'
class ExtractWeek(expression, tzinfo=None, **extra)  
 
lookup_name = 'week'
class ExtractWeekDay(expression, tzinfo=None, **extra)  
 
lookup_name = 'week_day'
class ExtractYear(expression, tzinfo=None, **extra)  
 
lookup_name = 'year'
class Trunc(expression, kind, output_field=None, tzinfo=None, is_dst=None, **extra)
class TruncDate(expression, tzinfo=None, **extra)  
 
lookup_name = 'date' 
  
output_field = DateField() 
  Changed in Django 3.2: The tzinfo parameter was added.
class TruncDay(expression, output_field=None, tzinfo=None, is_dst=None, **extra)  
 
kind = 'day'
class TruncHour(expression, output_field=None, tzinfo=None, is_dst=None, **extra)  
 
kind = 'hour'
class TruncMinute(expression, output_field=None, tzinfo=None, is_dst=None, **extra)  
 
kind = 'minute'
class TruncMonth(expression, output_field=None, tzinfo=None, is_dst=None, **extra)  
 
kind = 'month'
class TruncQuarter(expression, output_field=None, tzinfo=None, is_dst=None, **extra)  
 
kind = 'quarter'
class TruncSecond(expression, output_field=None, tzinfo=None, is_dst=None, **extra)  
 
kind = 'second'
class TruncTime(expression, tzinfo=None, **extra)  
 
lookup_name = 'time' 
  
output_field = TimeField() 
  Changed in Django 3.2: The tzinfo parameter was added.
class TruncWeek(expression, output_field=None, tzinfo=None, is_dst=None, **extra)  
Truncates to midnight on the Monday of the week.  
kind = 'week'
class TruncYear(expression, output_field=None, tzinfo=None, is_dst=None, **extra)  
 
kind = 'year'
class GenericIPAddressField(protocol='both', unpack_ipv4=False, **options)
GenericIPAddressField.protocol  
Limits valid inputs to the specified protocol. Accepted values are 'both' (default), 'IPv4' or 'IPv6'. Matching is case insensitive.
GenericIPAddressField.unpack_ipv4  
Unpacks IPv4 mapped addresses like ::ffff:192.0.2.1. If this option is enabled that address would be unpacked to 192.0.2.1. Default is disabled. Can only be used when protocol is set to 'both'.
get_lookup(lookup_name)  
Must return the lookup named lookup_name. For instance, by returning self.output_field.get_lookup(lookup_name).
get_transform(transform_name)  
Must return the lookup named transform_name. For instance, by returning self.output_field.get_transform(transform_name).
class ImageField(upload_to=None, height_field=None, width_field=None, max_length=100, **options)
ImageField.height_field  
Name of a model field which will be auto-populated with the height of the image each time the model instance is saved.
ImageField.width_field  
Name of a model field which will be auto-populated with the width of the image each time the model instance is saved.
class Index(*expressions, fields=(), name=None, db_tablespace=None, opclasses=(), condition=None, include=None)  
Creates an index (B-Tree) in the database.
JSONField.decoder  
An optional json.JSONDecoder subclass to deserialize the value retrieved from the database. The value will be in the format chosen by the custom encoder (most often a string). Your deserialization may need to account for the fact that you can’t be certain of the input type. For example, you run the risk of returning a datetime that was actually a string that just happened to be in the same format chosen for datetimes. Defaults to json.JSONDecoder.
JSONField.encoder  
An optional json.JSONEncoder subclass to serialize data types not supported by the standard JSON serializer (e.g. datetime.datetime or UUID). For example, you can use the DjangoJSONEncoder class. Defaults to json.JSONEncoder.
class Lookup  
A Lookup is a generic class to implement lookups. A lookup is a query expression with a left-hand side, lhs; a right-hand side, rhs; and a lookup_name that is used to produce a boolean comparison between lhs and rhs such as lhs in rhs or lhs > rhs. The primary notation to use a lookup in an expression is <lhs>__<lookup_name>=<rhs>. Lookups can also be used directly in QuerySet filters: Book.objects.filter(LessThan(F('word_count'), 7500))
 …or annotations: Book.objects.annotate(is_short_story=LessThan(F('word_count'), 7500))
  
lhs  
The left-hand side - what is being looked up. The object typically follows the Query Expression API. It may also be a plain value. 
  
rhs  
The right-hand side - what lhs is being compared against. It can be a plain value, or something that compiles into SQL, typically an F() object or a QuerySet. 
  
lookup_name  
The name of this lookup, used to identify it on parsing query expressions. It cannot contain the string "__". 
  
process_lhs(compiler, connection, lhs=None)  
Returns a tuple (lhs_string, lhs_params), as returned by compiler.compile(lhs). This method can be overridden to tune how the lhs is processed. compiler is an SQLCompiler object, to be used like compiler.compile(lhs) for compiling lhs. The connection can be used for compiling vendor specific SQL. If lhs is not None, use it as the processed lhs instead of self.lhs. 
  
process_rhs(compiler, connection)  
Behaves the same way as process_lhs(), for the right-hand side. 
  Changed in Django 4.0: Support for using lookups in QuerySet annotations, aggregations, and directly in filters was added.
lhs  
The left-hand side - what is being looked up. The object typically follows the Query Expression API. It may also be a plain value.
lookup_name  
The name of this lookup, used to identify it on parsing query expressions. It cannot contain the string "__".
process_lhs(compiler, connection, lhs=None)  
Returns a tuple (lhs_string, lhs_params), as returned by compiler.compile(lhs). This method can be overridden to tune how the lhs is processed. compiler is an SQLCompiler object, to be used like compiler.compile(lhs) for compiling lhs. The connection can be used for compiling vendor specific SQL. If lhs is not None, use it as the processed lhs instead of self.lhs.
process_rhs(compiler, connection)  
Behaves the same way as process_lhs(), for the right-hand side.
rhs  
The right-hand side - what lhs is being compared against. It can be a plain value, or something that compiles into SQL, typically an F() object or a QuerySet.
class lookups.RegisterLookupMixin  
A mixin that implements the lookup API on a class.  
classmethod register_lookup(lookup, lookup_name=None)  
Registers a new lookup in the class. For example DateField.register_lookup(YearExact) will register YearExact lookup on DateField. It overrides a lookup that already exists with the same name. lookup_name will be used for this lookup if provided, otherwise lookup.lookup_name will be used. 
  
get_lookup(lookup_name)  
Returns the Lookup named lookup_name registered in the class. The default implementation looks recursively on all parent classes and checks if any has a registered lookup named lookup_name, returning the first match. 
  
get_lookups()  
Returns a dictionary of each lookup name registered in the class mapped to the Lookup class. 
  
get_transform(transform_name)  
Returns a Transform named transform_name. The default implementation looks recursively on all parent classes to check if any has the registered transform named transform_name, returning the first match.
get_lookup(lookup_name)  
Returns the Lookup named lookup_name registered in the class. The default implementation looks recursively on all parent classes and checks if any has a registered lookup named lookup_name, returning the first match.
get_lookups()  
Returns a dictionary of each lookup name registered in the class mapped to the Lookup class.
get_transform(transform_name)  
Returns a Transform named transform_name. The default implementation looks recursively on all parent classes to check if any has the registered transform named transform_name, returning the first match.
ManyToManyField.db_constraint  
Controls whether or not constraints should be created in the database for the foreign keys in the intermediary table. The default is True, and that’s almost certainly what you want; setting this to False can be very bad for data integrity. That said, here are some scenarios where you might want to do this:  You have legacy data that is not valid. You’re sharding your database.  It is an error to pass both db_constraint and through.
ManyToManyField.db_table  
The name of the table to create for storing the many-to-many data. If this is not provided, Django will assume a default name based upon the names of: the table for the model defining the relationship and the name of the field itself.
ManyToManyField.limit_choices_to  
Same as ForeignKey.limit_choices_to.
ManyToManyField.related_name  
Same as ForeignKey.related_name.
ManyToManyField.related_query_name  
Same as ForeignKey.related_query_name.
ManyToManyField.swappable  
Controls the migration framework’s reaction if this ManyToManyField is pointing at a swappable model. If it is True - the default - then if the ManyToManyField is pointing at a model which matches the current value of settings.AUTH_USER_MODEL (or another swappable model setting) the relationship will be stored in the migration using a reference to the setting, not to the model directly. You only want to override this to be False if you are sure your model should always point toward the swapped-in model - for example, if it is a profile model designed specifically for your custom user model. If in doubt, leave it to its default of True.
ManyToManyField.symmetrical  
Only used in the definition of ManyToManyFields on self. Consider the following model: from django.db import models

class Person(models.Model):
    friends = models.ManyToManyField("self")
 When Django processes this model, it identifies that it has a ManyToManyField on itself, and as a result, it doesn’t add a person_set attribute to the Person class. Instead, the ManyToManyField is assumed to be symmetrical – that is, if I am your friend, then you are my friend. If you do not want symmetry in many-to-many relationships with self, set symmetrical to False. This will force Django to add the descriptor for the reverse relationship, allowing ManyToManyField relationships to be non-symmetrical.
ManyToManyField.through  
Django will automatically generate a table to manage many-to-many relationships. However, if you want to manually specify the intermediary table, you can use the through option to specify the Django model that represents the intermediate table that you want to use. The most common use for this option is when you want to associate extra data with a many-to-many relationship.  Note If you don’t want multiple associations between the same instances, add a UniqueConstraint including the from and to fields. Django’s automatically generated many-to-many tables include such a constraint.   Note Recursive relationships using an intermediary model can’t determine the reverse accessors names, as they would be the same. You need to set a related_name to at least one of them. If you’d prefer Django not to create a backwards relation, set related_name to '+'.  If you don’t specify an explicit through model, there is still an implicit through model class you can use to directly access the table created to hold the association. It has three fields to link the models. If the source and target models differ, the following fields are generated:  
id: the primary key of the relation. 
<containing_model>_id: the id of the model that declares the ManyToManyField. 
<other_model>_id: the id of the model that the ManyToManyField points to.  If the ManyToManyField points from and to the same model, the following fields are generated:  
id: the primary key of the relation. 
from_<model>_id: the id of the instance which points at the model (i.e. the source instance). 
to_<model>_id: the id of the instance to which the relationship points (i.e. the target model instance).  This class can be used to query associated records for a given model instance like a normal model: Model.m2mfield.through.objects.all()
ManyToManyField.through_fields  
Only used when a custom intermediary model is specified. Django will normally determine which fields of the intermediary model to use in order to establish a many-to-many relationship automatically. However, consider the following models: from django.db import models

class Person(models.Model):
    name = models.CharField(max_length=50)

class Group(models.Model):
    name = models.CharField(max_length=128)
    members = models.ManyToManyField(
        Person,
        through='Membership',
        through_fields=('group', 'person'),
    )

class Membership(models.Model):
    group = models.ForeignKey(Group, on_delete=models.CASCADE)
    person = models.ForeignKey(Person, on_delete=models.CASCADE)
    inviter = models.ForeignKey(
        Person,
        on_delete=models.CASCADE,
        related_name="membership_invites",
    )
    invite_reason = models.CharField(max_length=64)
 Membership has two foreign keys to Person (person and inviter), which makes the relationship ambiguous and Django can’t know which one to use. In this case, you must explicitly specify which foreign keys Django should use using through_fields, as in the example above. through_fields accepts a 2-tuple ('field1', 'field2'), where field1 is the name of the foreign key to the model the ManyToManyField is defined on (group in this case), and field2 the name of the foreign key to the target model (person in this case). When you have more than one foreign key on an intermediary model to any (or even both) of the models participating in a many-to-many relationship, you must specify through_fields. This also applies to recursive relationships when an intermediary model is used and there are more than two foreign keys to the model, or you want to explicitly specify which two Django should use.
class Max(expression, output_field=None, filter=None, default=None, **extra)  
Returns the maximum value of the given expression.  Default alias: <field>__max
 Return type: same as input field, or output_field if supplied
class Min(expression, output_field=None, filter=None, default=None, **extra)  
Returns the minimum value of the given expression.  Default alias: <field>__min
 Return type: same as input field, or output_field if supplied