DEV Community 👩‍💻👨‍💻

Arjun Adhikari
Arjun Adhikari

Posted on • Updated on

Create Django App and Migrations

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.

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.

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
Enter fullscreen mode Exit fullscreen mode

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.

For now, we're going to add the app we created into the INSTALLED_APPS 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',
]
Enter fullscreen mode Exit fullscreen mode

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.

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
Enter fullscreen mode Exit fullscreen mode

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.

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Now, you've successfully created the app and migration with Django. In next installment of the series, I'll be guiding to fetch the weather data from the public API and building beautiful frontend afterwards, Till then, keep coding :)

Top comments (0)

🌚 Browsing with dark mode makes you a better developer.

It's a scientific fact.