Create Django App and Migrations
Tags: django, python, webdev, tutorial
Published: 2020-04-19 17:31:43

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
```

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',
]
```
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
```
 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
```
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. 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 :)`