Database Setup and Seeding

Relevant source files

The following files were used as context for generating this wiki page:

• reset_production_db.py
• becathlon/settings.py
• pbp-deploy.sh
• IMPLEMENTATION.md
• README.md
• apps/main/models.py
• apps/stores/models.py

The Becathlon project employs a flexible database setup that supports both SQLite for local development and PostgreSQL for production environments. The system includes automated scripts and Django fixtures to initialize the database schema, apply migrations, and populate it with essential starting data. This ensures a consistent and reproducible environment for both developers and the deployed application.

The setup process involves conditional database configuration, automated migration execution during deployment, and scripts for complete database resets. Initial data, such as product categories and store locations, is loaded through a combination of Python scripts and JSON fixtures.

Database Configuration

The database connection is dynamically configured in becathlon/settings.py. The application checks for the presence of specific environment variables to determine whether to connect to a PostgreSQL database or fall back to a local SQLite file.

Sources: becathlon/settings.py:102-132

Configuration Logic

The logic prioritizes a PostgreSQL connection if all required environment variables (DB_NAME, DB_USER, DB_PASSWORD, DB_HOST) are set. Otherwise, it defaults to SQLite, which is ideal for local development without requiring a separate database server.

The following diagram illustrates the database configuration flow.

Environment Variables

For a production (PostgreSQL) setup, the following environment variables must be defined:

Variable	Description	Default Value
DB_NAME	The name of the PostgreSQL database.	None
DB_USER	The username for the database connection.	None
DB_PASSWORD	The password for the database user.	None
DB_HOST	The hostname or IP address of the database server.	None
DB_PORT	The port number for the database server.	5432
SCHEMA	The specific PostgreSQL schema to use.	None

Sources: becathlon/settings.py:103-108

Database Initialization and Migration

Database initialization is handled through standard Django migrations, which are applied automatically during deployment or can be run manually. For a clean slate, especially in production, a dedicated reset script is provided.

Production Deployment

The pbp-deploy.sh script, executed during production deployment, ensures that database migrations are always applied. This keeps the database schema in sync with the models defined in the code.

# pbp-deploy.sh
...
# Run migrations
echo "Running database migrations..."
python manage.py migrate --noinput
...

Sources: pbp-deploy.sh:13-14

Production Database Reset

The reset_production_db.py script provides a powerful but destructive way to completely reset the production database. It is intended for initial setup or recovery from severe migration conflicts.

CAUTION: This script deletes all data in the configured database.

The script performs the following actions:

1. Prompts the user for explicit confirmation (YES DELETE EVERYTHING).
2. Connects to the database and drops all existing tables.
3. Runs django.core.management.call_command('migrate') to recreate the entire schema from scratch.
4. Executes seed_product_types.py to populate the ProductType table with initial data.

The following diagram shows the workflow of the production reset script.

Data Seeding

The project uses two primary methods for seeding initial data: a Python script for product types and Django fixtures for other models like stores and products.

Product Types Seeding

The seed_product_types.py script is responsible for creating the initial set of sport categories. It is executed by the reset_production_db.py script after migrations are complete.

*Sources: reset_production_db.py:72-77, IMPLEMENTATION.md

The pre-seeded product types are:

Product Type
Running
Cycling
Swimming
Fitness
Team Sports
Racket Sports
Hiking
Camping
Water Sports
Winter Sports
Yoga
Boxing

*Sources: IMPLEMENTATION.md

Fixture-Based Seeding

The project also uses Django's fixture system to load initial data from JSON files. This is mentioned for both stores and catalog applications. Fixtures are typically loaded using the manage.py loaddata <fixture_name> command.

*Sources: README.md

Store Locations

The apps/stores/fixtures/stores.json file contains initial data for physical store locations. Based on the stores app models, the fixture likely contains data for the following fields:

Field	Type	Description
name	String	The name of the store location.
address	String	The physical street address of the store.
city	String	The city where the store is located.
country	String	The country of the store.
latitude	Float	The geographical latitude of the store.
longitude	Float	The geographical longitude of the store.
store_hours	String	The opening and closing times of the store.
phone	String	The contact phone number for the store.

*Sources: README.md, apps/stores/models.py

Product Catalog

A fixture at apps/catalog/fixtures/products.json is also mentioned for populating the product catalog with an initial set of products.

*Sources: README.md

Data Model Relationships

The following ER diagram shows the relationships between the key models that are populated during the seeding process.

This diagram illustrates that each Product must belong to one ProductType. The Store model is independent but is also populated via fixtures.

Sources: IMPLEMENTATION.md, README.md