How parisa-reza/owner-rental-parisa-reza works
1. This is a single Django monolith with one business app
- The repository is organized around a Django project (core) and one main domain app (property_app).
- manage.py, core/asgi.py, core/wsgi.py, and core/urls.py define the standard Django entrypoints and URL root.
2. property_app is the center of the domain
- The app contains the property data model, admin configuration, web pages, and a small API layer.
- From the README and migrations, the core entities are Location, Property, and PropertyImage.
3. Persistence is split between relational, spatial, and vector concerns
- PostgreSQL is used as the primary database.
- PostGIS backs the geographic/location features and distance-based queries.
- pgvector stores location embeddings for semantic search, with an HNSW index created on the embedding field.
4. Data ingestion is a separate batch pipeline
- rentals.csv is the source file for bulk import.
- property_app/management/commands/import_properties.py is the ingestion boundary: it reads CSV rows, creates/updates locations and properties, and generates embeddings.
- Pandas is used for CSV processing, and the importer is responsible for populating both the spatial and semantic search fields.
5. Geospatial search is one of the main runtime flows
- The UI search form on the homepage feeds location-based queries.
- The backend uses GeoDjango/PostGIS to find properties by physical proximity and to calculate/display distance from the city center or location hub.
- The README describes a location-anchor pattern where the first property in a city establishes the location hub and later properties reuse it.
6. Semantic search is a second runtime flow layered on top
- Location text is transformed into embeddings using Sentence Transformers (all-MiniLM-L6-v2).
- Those embeddings are stored in pgvector and queried with cosine distance via the HNSW index.
- This search path is conceptually separate from the geographic path, but both resolve to the same Location/Property records.
7. The web UI is server-rendered Django templates
- property_app/templates/property_app/ contains the main pages: home.html, listing.html, detail.html, and base.html.
- This suggests classic server-side rendering for browse/search/detail flows rather than a SPA.
- property_app/views.py and property_app/urls.py likely drive these pages.
8. There is a small client-side enhancement layer
- property_app/static/property_app/js/autocomplete.js indicates browser-side autocomplete behavior, likely tied to the search form.
- Static assets are packaged under the app, alongside images used by the templates.
9. An API exists, but it is secondary to the HTML app
- property_app/api/views.py, serializers.py, and urls.py define a Django REST-style API boundary.
- The API likely exposes property/location data for programmatic access or search results, while the main user journey remains template-based.
10. Django Admin is used as an operational back office
- property_app/admin.py and the README indicate custom filters, sortable columns, and inline image previews.
- This is the primary internal tooling surface for inspecting and managing imported properties and media.
11. Images are stored in Django media storage
- Property photos live under media/properties/..., so image assets are persisted separately from code and database rows.
- PropertyImage likely links database records to files in the media directory.
12. Docker is the deployment and local runtime boundary
- Dockerfile and compose.yml define the app and its database environment.
- The README shows the intended runtime is containerized Django plus PostgreSQL with required extensions enabled.
- .env.example suggests configuration is environment-driven.
13. Migrations encode the evolution of the spatial/vector schema
- 0001_initial.py through 0003_location_location_embedding_idx.py show the schema matured from basic entities to geo fields and then vector indexing.
- This is important for the architecture diagram because the database is not just relational; it is explicitly specialized for geospatial and semantic retrieval.
14. Overall data flow
- CSV import populates the database and generates embeddings.
- Users interact through the homepage search, listing page, and detail page.
- Requests are handled by Django views, which query either PostGIS, pgvector, or both, then render templates or return API responses.
- Admin users and management commands act as the main non-user-facing control paths.
Main entry points: views.py Search pages · models.py Property model · import_properties.py CSV importer · Dockerfile Docker
Components 19
Runtime
Django request handling, templated UI, and API surface
- manage.py · Command-line entry for Django management tasks
manage.py - URL root · Project-level URL configuration and request entry routing
core/urls.py - WSGI · Production server entrypoint
core/wsgi.py - ASGI · Async/server entrypoint
core/asgi.py - Search pages · Server-rendered homepage, listing, and detail flows
property_app/views.py - Templates · Base, home, listing, and detail Django templates
property_app/templates/property_app - Autocomplete · Small browser-side enhancement for search input
property_app/static/property_app/js/autocomplete.js - Property API · Programmatic boundary for property and location data
property_app/api
Domain app
Property data model, search flows, admin, and import pipeline
- Admin · Django admin configuration for inspecting and managing properties
property_app/admin.py - Property model · Location, Property, and PropertyImage entities
property_app/models.py - CSV importer · Management command that ingests rentals.csv and populates search fields
property_app/management/commands/import_properties.py - Schema migrations · Progression from core entities to spatial fields and vector indexing
property_app/migrations
Data & storage
Persistent storage and media assets
- PostgreSQL · Primary database for property records
- PostGIS · Spatial search and distance calculations
- pgvector · Embedding storage and cosine similarity search
- Media files · Stored property images under media/properties
media/properties
Deployment
Containerized runtime and configuration
- Docker · Container build and compose setup for app and database
Dockerfile - Compose · Local multi-service runtime definition
compose.yml - Env config · Environment-driven settings template
.env.example
Connections 25
- manage.py → URL root: boots app · Django management uses project settings and URL routing
- URL root → Search pages: routes to · Root requests reach the server-rendered property views
- URL root → Property API: routes to · API endpoints are mounted under the project URL tree
- Search pages → Templates: renders · Views render HTML templates for browse and detail pages
- Search pages → Property model: queries · Views read property and location records
- Search pages → PostGIS: nearby search · Geospatial lookup and distance-based filtering
- Search pages → pgvector: semantic search · Embedding-based location matching
- Autocomplete → Search pages: enhances · Autocomplete supports the search form on the homepage
- Property API → Property model: serializes · API exposes domain records for programmatic clients
- Admin → Property model: manages · Admin screens operate on the core domain entities
- CSV importer → Property model: creates/updates · Bulk import populates locations, properties, and images
- CSV importer → pgvector: writes embeddings · Importer generates and stores location embeddings
- CSV importer → PostGIS: fills geo fields · Importer populates spatial data used for proximity queries
- CSV importer → Media files: links files · Imported properties reference stored media assets
- Schema migrations → Property model: evolves · Migrations define the database shape for the domain models
- Schema migrations → PostGIS: enables · Adds spatial fields and geo-supporting schema
- Schema migrations → pgvector: indexes · Creates the embedding index for vector search
- Property model → PostgreSQL: persists to · Core entity storage lives in PostgreSQL
- PostGIS → PostgreSQL: extends · Spatial capabilities are provided through PostgreSQL
- pgvector → PostgreSQL: extends · Vector search capabilities are provided through PostgreSQL
- Docker → Compose: packages · Docker image is run through the compose service setup
- Compose → PostgreSQL: starts db · Compose defines the database service alongside the app
- Docker → Env config: reads config · Container runtime is configured from environment variables
- WSGI → Docker: served by · WSGI deployment runs inside the containerized app runtime
- ASGI → Docker: served by · ASGI deployment runs inside the containerized app runtime