vinisha-a/qualix_final

This repository is a Django-based data quality platform organized as a single monolith with multiple domain apps. The main runtime entry points are manage.py, Django wsgi.py/asgi.py, and a Celery setup in data_quality/celery.py, which indicates that some validation/workflow execution happens asynchronously.

The core architectural boundary is between the web UI and the backend domain logic. The UI is server-rendered with Django templates (templates/, plus per-app templates), shared layout components, and static assets under static/. There is no separate frontend app; pages for setup, configuration, execution, and reporting are rendered by the Django server.

Authentication and user administration live in accounts/. This app handles login, password recovery, SSO selection, user management, decorators, and context processors, so it forms the access-control layer for the rest of the platform.

connections/ is the source-system integration boundary. It stores connection definitions and credentials, exposes forms and views for creating/listing connections, and contains a connector.py module that likely encapsulates the actual connection/session logic. This app is the bridge from the platform into external data sources such as Databricks, PostgreSQL, MySQL, Oracle, DB2, CSV, and Parquet, as described in the README.

mappings/ defines how data should be interpreted or transformed before validation. Its models and views support creation, editing, and listing of mappings, and the migrations show substantial evolution around date filtering, relative date operators, source date columns, sum/length fields, draft state, and validation rule operations. This is the configuration layer for validation logic, not the execution layer itself.

validations/ is the execution and reporting subsystem for data quality checks. It contains a engine.py for rule execution and tasks.py for background processing, plus models for validation runs and selected parameters. The templates include progress and report pages, which suggests runs are launched asynchronously and then surfaced through a UI that tracks status and displays results.

workflows/ is the orchestration layer for scheduled or trigger-driven processing. The presence of tasks.py, trigger_engine.py, and migrations for high-water-mark tables and DB trigger fields suggests this app manages repeatable execution, incremental processing, and event/trigger-based workflows rather than only one-off validation runs.

dashboard/ is the monitoring and landing area. It provides the main index/help pages and includes a notification model, so it likely aggregates recent runs, system status, and user-facing alerts. This is the primary reporting surface after validations and workflows complete.

The end-to-end data flow is: user authenticates through accounts, configures a source in connections, defines business logic in mappings, executes checks through validations or workflows, and reviews outcomes in dashboard and validation report pages. The database-backed models across apps are the system of record for configuration, execution history, and reporting.

The codebase is structured around Django apps with their own URLs, views, models, templates, and migrations. That separation is important for an architecture diagram: each app is a domain boundary, while Django settings and shared templates/static files provide the cross-cutting application shell.

Celery is the main infrastructure piece besides the relational database. It likely handles long-running validation and workflow jobs, allowing the UI to show progress without blocking web requests. That makes the platform suitable for large enterprise data sources and batch-oriented quality checks.

In diagram terms, the key external interfaces are: authenticated browser users, database-backed application state, background task execution via Celery, and remote data sources accessed through the connector engine. The central architectural theme is configuration-driven data quality processing with async execution and reporting.