You will use two main field types for simple text fields.

The CharField type is designed for smaller strings with specific length limitations, such as names or titles. CharField tells Django that the field is expecting text data. It requires that a maximum length be specified using the max_length argument:

name = models.CharField('Name', max_length=100)

The TextField type is designed for larger strings of text, such as a description. TextField tells Django that the field is expecting a variable amount of text. You can specify a maximum size for TextField using the max_length argument, as shown here, but this is not required:

desc = models.TextField('Desc', max_length=1000)

You can use three different types of fields when adding date and time fields to your models. DateField, TimeField, and DateTimeField are designed to accept a date, time, and date with time of day value, respectively:

    bday = models.DateField('Birthday')
    alarm = models.TimeField('Alarm')
    appnt = models.DateTimeField('Appointment')

All three date and time field types accept the following two optional arguments:

You will use two types of file fields. The first is the standard FileField, which is used to upload files to the website. FileField requires an upload_to argument that specifies a path, relative to MEDIA_ROOT, on the local file system of the web server to store the file, as shown here:

doc = models.FileField('File', upload_to='documents')

The second type of field is the ImageField. The ImageField is very similar to the FileField except that in validation, the ImageField will validate the file as a valid image file. The ImageField also includes two extra optional arguments, height_field and width_field that contain height and width of the image. These fields are autopopulated when the object is saved.

location = models.URLField('WebPage', verify_exists=True, max_length=100)

Django provides two different options that allow you to leave fields blank when adding new objects. The null option tells Django to store any fields left blank as the NULL in the database:

count = models.Integer('count', null=True)

The blank option tells Django’s validation engine to allow the field to be left blank:

count = models.Integer('count', blank=True)

There is a big difference between the null and blank options. The null option is strictly at the database level. The blank option is used by the validation engine on the Django admin site. This means that if you want to allow null values to be stored in the database and accessed in your code, you will need to set both the null and blank options to True.

The default option allows you to specify a value that will be applied to the field by default:

title = models.Integer('Title', default='<no title>')

The choices field option allows you to specify a list of two tuples to use as viable values in the field. Django’s model validation accepts only values specified in the choices field option when validating form entry. When this option is used, the Django admin interface provides a selection box for you to make your choice.

This code snippet shows how to add a list of choices to a field definition:

gender_list = (('M', 'Male'), ('F', 'Female' ))
. . .
    gender = models.CharField(max_length=1, choices=gender_list)

The core field option is used when you relate objects to another object in the model. The Django admin interface lets you specify that multiple objects that are related to each other can be edited inline together.

Fields that have core=True set are treated as required fields in the object. When all the fields that have core=True set are cleared in the admin interface, the object is deleted.

The editable field can be useful if you have a field, such as the modified time stamp shown here, that you do not want to be edited by the admin interface or Django’s default forms. Fields are editable by default. However, if you specify editable=False, they cannot be changed in Django’s admin interface:

last_modified = models.DateTimeField('Last Modified', auto_now_add=True,
  editable=False)

The primary_key field option allows you to specify which field will be used for the primary key in the database. If you set primary_key=True for a field, blank=False, null=False, and unique=True are implied for the field. Only one primary key is allowed per object.

id=models.AutoField('ID', primary_key=True)

The unique field option allows you to specify if you want the field’s value to be unique throughout the table in the database. When unique=True is set, values are not allowed if they already exist for that field in another object in the database. The unique option is enforced at both the Django admin validation level and the database level.

Django also provides the following field options that allow you to specify uniqueness of objects based on date:

Arguably the most common type of relationship you will deal with is the many-to-one relationship, in which one object can be related to several others.

Many-to-one relationships are defined by adding a ForeignKey field to a class and specifying a second class as the key. For example, our sample website currently has a Person class defined. If we were to add a Hometown class, several people might come from the same hometown. The code used to define the many-to-one relationship would be similar to the following:

class Hometown(models.model):
. . .
class Person(models.Model):
    hometown = models.ForeignKey(Hometown)

class Person(models.Model):
    hometown = models.ForeignKey('Hometown')
. . .
class Hometown(models.model):

. . . models.ForeignKey('self')

The following are some of the more common optional arguments that you will use with ForeignKey:

Many-to-many relationships are defined by adding a ManyToMany field to a class and specifying a second class as the key. For example, our sample website currently has a Person class defined. If we were to add a Blog class, we might have several persons who belong to several blogs and several blogs that have several people using them. The code used to define the many-to-many relationship would be similar to the following:

class Blog(models.model):
. . .
class Person(models.Model):
    blogs = models.ManyToManyField(Blog)

friends = models.ManyToManyField('self')

The following are some of the more common optional arguments you will use with ManyToManyField:

Quoted from djangoproject.com: “The semantics of one-to-one relationships will be changing soon, so we don’t recommend that you use them.”

One-to-one relationships are defined by adding a OneToOne field to a class and specifying a second class as the key. For example, our sample website currently has a Person class defined. If we were to add an Alias class that limits each person to have only one Alias, the code used to define the one-to-one relationship would be similar to the following:

class Alias(models.model):
. . .
class Person(models.Model):