How to share database details in Github correctly, using Django and PostgreSQL?-CodePudding

I have an assignment in which I need to set up a database server using Python Django and PostgreSQL. I need to assign the project in Github, and the grader will use my repository to check my project.

In my setting.py file I have the following lines:

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.postgresql',
        'NAME': 'CourseDB',
        'USER': 'postgres',
        'PASSWORD': '123',
        'HOST': 'localhost',
        'PORT': '5432'
    }
}

What to do so the details on my file will be correct for the grader's side?

Will they have to create a database with the given name, user and password like the ones in my file?

I think that maybe for the database name, I can add in the readme to run CREATE DATABASE CourseDB first. But then again, I don't know their user and password on their machine, So I don't know what should be written in my file in order for my code to work on their machine.

I followed this tutorial on YouTube to create my file.

CodePudding user response：

Unless you need some Postgres specific functionality, you can use the default SQLite backend:

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.sqlite3',
        'NAME': BASE_DIR / 'db.sqlite3',
    }
}

Django will automatically create a database file. No setup/user/password needed.

CodePudding user response：

In general, a good practice is to save all the DB sensitive credentials in settings.py using env vars like the following:

import os

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.postgresql',
        'NAME': os.environ['DATABASE_NAME'],
        'USER': os.environ['DATABASE_USER'],
        'PASSWORD': os.environ['DATABASE_PASSWORD'],
        'HOST': os.environ['DATABASE_HOST'],
        'PORT': os.environ['DATABASE_PORT'],
    }
}

Several DB backends are natively supported (see the official docs here) including PostgreSQL, MariaDB, MySQL, Oracle and SQLite and a number of additional backends provided by third parties.

If you go with the SQLite backend (for sure the best alternative for quick development and MVPs), keep in mind that there are some differences specific to the SQLite backend that you should take into consideration (e.g. not supported features).