Pylenin Weekly #11

Welcome to Pylenin Weekly #11, a newsletter dedicated to improving the lives of my fellow peers through knowledge sharing in the field of programming and Data.

A lot of people have asked me to discuss the way I set my database settings for Django and Flask. So we are going to discuss the same in this newsletter.

Add a new database to settings.py

Don't replace the default!

When you create a basic Django project, this is what your settings.py looks like.

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.sqlite3',
        'NAME': os.path.join(BASE_DIR, 'db.sqlite3'),
    }
}

Initially, when you are testing, it is good to work with the default SQLite3 database and move to a more sophisticated database like Postgresql or MySql, once the basic functionality is there.

Now a lot of the developers I have worked with will just go ahead and replace the SQLite3 database. But IMHO, that is a ROOKIE move!

You should never remove the default database on which you have built the staging version of your website. Either replace the default from the start with a database of your choice or add a new key:value pair to the DATABASES dictionary.

This is what I propose!

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.sqlite3',
        'NAME': os.path.join(BASE_DIR, 'db.sqlite3'),
    },
    'prod': {
        'ENGINE': 'django.db.backends.mysql',
        'NAME': 'Lenin Mishra',
        'USER': 'pylenin',
        'PASSWORD': '@1234A56789#',
        'HOST': '<mysql-host-provider>',
        'PORT': '3306',
    }
}

This way, you can always have access to both the staging and production environments.

By default, you will always be working on the staging environment.So when you run python manage.py migrate, it is always going to apply the changes to the default SQLite3 database.

Once you are sure of your changes, you can go ahead and apply the changes to your production database using the below command.

 python manage.py migrate --database=prod

How to transfer data from default to prod DB in Django?

Initially, if you want to move the data from staging to production, you can easily do it with the following commands.

python manage.py dumpdata > staging.json
python manage.py loaddata staging.json --database=prod

If you have any questions or doubts on how to do manage your database settings better with Django, make sure to tweet to me!

I don't think it improves the readability of the code and that's the problem with many programmers. They like to over complicate things just for the sake of it, because it's fun and challenging to do so. But sometimes it can get very confusing for people who haven't written this code and try to understand it. A print() statement would have been more intuitive. Just my opinion. Nevertheless I learned a lot from this video so many thanks for that.

This comment was posted on the video of Custom Exception Classes. First of all, I really appreciate the honesty of the person who has given this comment. Though I don't completely agree with this opinion, I do agree to the idea that, readability is a concept of the team you are working in. Some people find functional programming to be readable, some think Object oriented programming is better than functional programming. Neither is wrong!

Coming to the point of using custom exception classes, the big advantage is that it allows you to throw exceptions that is sensible to you and the team. If you reuse an existing exception, any piece of your code that catches the exception has to deal with possibility that the actual exception wasn't thrown by your code, but by some other library party code.

But it is absolutely your choice! Check out the video here.

I hope you enjoyed today's newsletter! Next week, I will be back with some other interesting articles on Python and data related concepts.

To suggest any article or topic for me to focus on for the next newsletter, tweet to me!

See you again next week!