Hello pals, I hope you’re following me through the first installment of the series ‘Create Django Project’. Upto then, I’ve created a django project named weather_project.

Project & Apps : What’s the fuss ?

The typical next step is to start adding apps, which represent discrete areas of functionality. A single Django project can support multiple apps. So, I am creating an app inside the Django project for managing my application logic conveniently.

It may seem confusing with the project that I’ve created and the app I’m going to create now. The main difference between app and project in Django is well illustrated as :

A project refers to the entire application and all its parts. An app refers to a submodule of the project. It’s self-sufficient and not intertwined with the other apps in the project such that, in theory, you could pick it up and plop it down into another project without any modification. The main thing to keep in mind is this level of interdependence between the apps. In practice it’s all one project, so there’s no sense in going overboard, but keep in mind how co-dependent two apps are. If you find one app is solving two problems, split them into two apps. If you find two apps are so intertwined you could never reuse one without the other, combine them into a single app.

Create Django App

Now, let’s create an app named weather inside the project. For creating the app, we are using startapp command . python manage.py startapp weather

Executing the startapp command, Django will automatically create the app for us and we can visualize the directory structure which looks like:

weather
├── admin.py
├── apps.py
├── __init__.py
├── migrations
│   └── __init__.py
├── models.py
├── tests.py
└── views.py

1 directory, 7 files

Don’t worry, pal. I will be guiding you through each of the files.

Each app has a __init__.py file identifying it as a Python package. There are 6 new files created: • admin.py is a configuration file for the built-in Django Admin app. • apps.py is a configuration file for the app itself. • The migrations directory stores migrations files for database changes. • models.py is where we define our database models. • tests.py is for our app-specific tests. • views.py is where we handle the request/response logic for our web app. Typically developers will also create an urls.py file within each app too for routing.

Post App-Creation Setup

After app creation, we’re going to add the app we created into the INSTALLED_APPS list inside the settings.py.

# weather_project/settings.py
-----------------------------
INSTALLED_APPS  = [
'django.contrib.admin',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.messages',
'django.contrib.staticfiles',

# Local
'weather.apps.WeatherConfig',
]

Notice that, I’ve separated the 'weather.apps.WeatherConfig' from the rest for the convenience. It makes easier to look after the apps we created.

Database Schema in Django Flavour : Models

After adding the app to INSTALLED_APPS, now I’m defining the database requirements. For storing the database information, we need following fields.

  • city_name
  • updated_at - You’ll know why I created this field afterwards. Just stick to it.

After analysing the database requirements, let’s define those fields in models.py Django ORM helps us to create the schema without writing the SQL commands. That’s the power of fully featured web framework.

# weather/models.py
--------------------
from django.db import models

class  WeatherModel(models.Model):

	city_name = models.CharField(max_length=100)
	updated_at = models.DateTimeField(auto_now=True)

	def  __str__(self):
		return  self.city_name

The city_name can be maximum of 100 characters and the updated_at fields get updated to the latest timestamp when we make any update to the record afterwards. We also include a __str__ method so that the city name is appeared in the Admin Panel later.

Makemigrations and Migrate

Thenceforth, run the makemigrations to generate the DDL(Data Definition Language ) commands for your database. Don’t get intimidated by two similar words: makemigrations and migrate. The difference in simple words seems to be : python manage.py makemigrations: Create the migrations (generate the SQL commands). python manage.py migrate: Run the migrations (execute the SQL commands).

Always remember you’re making migrations first and then running the migration.

While making the migrations:

Terminal
---------
$ python manage.py makemigrations
Migrations for 'weather':
  weather/migrations/0001_initial.py
    - Create model WeatherModel

And while running the migration,

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

Now, you’ve successfully created the app and migration with Django.

Thanks for reading.