mirror of
https://github.com/pacnpal/thrillwiki_django_no_react.git
synced 2025-12-20 06:51:08 -05:00
751cd86a31
- Implemented OperatorListView and OperatorDetailView for managing operators. - Created corresponding templates for operator listing and detail views. - Added PropertyOwnerListView and PropertyOwnerDetailView for managing property owners. - Developed templates for property owner listing and detail views. - Established relationships between parks and operators, and parks and property owners in the models. - Created migrations to reflect the new relationships and fields in the database. - Added admin interfaces for PropertyOwner management. - Implemented tests for operators and property owners.
55 lines
2.2 KiB
Plaintext
55 lines
2.2 KiB
Plaintext
# Project Startup Rules
|
|
|
|
## Development Server
|
|
IMPORTANT: Always follow these instructions exactly when starting the development server:
|
|
|
|
```bash
|
|
lsof -ti :8000 | xargs kill -9; find . -type d -name "__pycache__" -exec rm -r {} +; uv run manage.py tailwind runserver
|
|
```
|
|
|
|
Note: These steps must be executed in this exact order as a single command to ensure consistent behavior.
|
|
|
|
## Package Management
|
|
IMPORTANT: When a Python package is needed, only use UV to add it:
|
|
```bash
|
|
uv add <package>
|
|
```
|
|
Do not attempt to install packages using any other method.
|
|
|
|
## Django Management Commands
|
|
IMPORTANT: When running any Django manage.py commands (migrations, shell, etc.), always use UV:
|
|
```bash
|
|
uv run manage.py <command>
|
|
```
|
|
This applies to all management commands including but not limited to:
|
|
- Making migrations: `uv run manage.py makemigrations`
|
|
- Applying migrations: `uv run manage.py migrate`
|
|
- Creating superuser: `uv run manage.py createsuperuser`
|
|
- Starting shell: `uv run manage.py shell`
|
|
|
|
NEVER use `python manage.py` or `uv run python manage.py`. Always use `uv run manage.py` directly.
|
|
|
|
## Entity Relationship Rules
|
|
IMPORTANT: Follow these entity relationship patterns consistently:
|
|
|
|
# Park Relationships
|
|
- Parks MUST have an Operator (required relationship)
|
|
- Parks MAY have a PropertyOwner (optional, usually same as Operator)
|
|
- Parks CANNOT directly reference Company entities
|
|
|
|
# Ride Relationships
|
|
- Rides MUST belong to a Park (required relationship)
|
|
- Rides MAY have a Manufacturer (optional relationship)
|
|
- Rides MAY have a Designer (optional relationship)
|
|
- Rides CANNOT directly reference Company entities
|
|
|
|
# Entity Definitions
|
|
- Operators: Companies that operate theme parks (replaces Company.owner)
|
|
- PropertyOwners: Companies that own park property (new concept, optional)
|
|
- Manufacturers: Companies that manufacture rides (replaces Company for rides)
|
|
- Designers: Companies/individuals that design rides (existing concept)
|
|
|
|
# Relationship Constraints
|
|
- Operator and PropertyOwner are usually the same entity but CAN be different
|
|
- Manufacturers and Designers are distinct concepts and should not be conflated
|
|
- All entity relationships should use proper foreign keys with appropriate null/blank settings |