Today in django tutorial series we define 2 models in polls/models.py. One for Question and another for Choice.

from django.db import models
class Question(models.Model):
    question_text = models.CharField(max_length=200)
    pub_date = models.DateTimeField('date published')

class Choice(models.Model):
    question = models.ForeignKey(Question, on_delete=models.CASCADE)
    choice_text = models.CharField(max_length=200)
    votes = models.IntegerField(default=0)

Our model's parent class is django models.Model and each model has its own fields. You can define string field by CharField, integer by IntegerField and datetime by DateTimeField.

* The name of each field is the column name in the table.

* max_length can be given as an argument to put restrictions on field's length

* you can give a human readable name to each field by providing an optional first positional argument like pub_date which is set to date published

* you can define foreign keys by models.ForeignKey

* fields can have default value is we have set for votes by using default

Until now Django knows nothing about our polls app, we need to plug it in, in order to include it in our project. Go to saturn/settings.py and do as follow:

INSTALLED_APPS = [
    'polls.apps.PollsConfig',
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
]

Now use makemigrations command to tell Django to store new model changes in migrations folder inside of polls:

$ python manage.py makemigrations polls
Migrations for 'polls':
  polls/migrations/0001_initial.py
    - Create model Choice
    - Create model Question
    - Add field question to choice

Finally use the below command to create the tables:

$ python manage.py migrate
Operations to perform:
  Apply all migrations: admin, auth, contenttypes, polls, sessions
Running migrations:
  Applying polls.0001_initial... OK

migrate is smart and just applies those changes needed, if you are careful enough you can see that a file is created that is called polls.0001_initial. This file is created by our command makemigrations in the previous step.

So we've done 2 steps overall:
1- used makemigrations to create migration files.
2- applied the migration generated in step 1 by using migrate.

#python #django #migrate #models #migrate #makemigrations #django_part5

What does select_related do in Django?

select_related does a join in case needed on the DB side and reduce query counts. Let's look at an example:

# Hits the database.
e = Entry.objects.get(id=5)

# Hits the database again to get the related Blog object.
b = e.blog

In the above code 2 queries are issued in DB side. First it gets Entry record and then blog is fetched from DB when e.blog is called. And here’s select_related lookup:

# Hits the database.
e = Entry.objects.select_related('blog').get(id=5)

# Doesn't hit the database, because e.blog has been prepopulated
# in the previous query.
b = e.blog

You can follow foreign keys in a similar way to querying them. If you have the following models:

from django.db import models

class City(models.Model):
    # ...
    pass

class Person(models.Model):
    # ...
    hometown = models.ForeignKey(
        City,
        on_delete=models.SET_NULL,
        blank=True,
        null=True,
    )

class Book(models.Model):
    # ...
    author = models.ForeignKey(Person, on_delete=models.CASCADE)

Then a call to Book.objects.select_related('author__hometown').get(id=4) will cache the related Person and the related City:

# Hits the database with joins to the author and hometown tables.
b = Book.objects.select_related('author__hometown').get(id=4)
p = b.author         # Doesn't hit the database.
c = p.hometown       # Doesn't hit the database.

# Without select_related()...
b = Book.objects.get(id=4)  # Hits the database.
p = b.author         # Hits the database.
c = p.hometown       # Hits the database.

#python #django #select_related #join #database #models