mirror of
https://github.com/Hestia-Homes/Model.git
synced 2026-07-12 13:29:04 +00:00
b1ff711260
Even after batching the data writes, the handler still wrote to the DB per property through the orchestrator's SubTask bookkeeping: create + start + complete each self-committed, and _cascade re-listed every sibling and re-saved the parent on every transition — ~5 writes per property plus an O(N^2) cascade. - TaskOrchestrator.run_subtasks: create all children in one INSERT, run each (failures isolated per child), then persist all terminal states in one bulk save and cascade the parent once. Children go WAITING -> terminal; the transient IN_PROGRESS row is never written. - SubTaskRepository.create_many / save_many (bulk INSERT / bulk fetch + update). - _cascade short-circuits when the Task is already FAILED (terminal) — skips the sibling roll-up entirely. - modelling_e2e handler fans out via run_subtasks instead of per-property create_child_subtask + run_subtask. Per N-property batch the SubTask bookkeeping drops from ~5N writes + an O(N^2) cascade to ~2 writes + 1 cascade. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| __init__.py | ||
| ara_first_run_pipeline.py | ||
| audit_generator_orchestrator.py | ||
| audit_generator_unit_of_work.py | ||
| bulk_upload_finaliser_orchestrator.py | ||
| classifiable_column.py | ||
| ingestion_orchestrator.py | ||
| landlord_description_overrides_orchestrator.py | ||
| magic_plan_orchestrator.py | ||
| modelling_orchestrator.py | ||
| postcode_splitter_orchestrator.py | ||
| property_baseline_orchestrator.py | ||
| sharepoint_renamer_orchestrator.py | ||
| task_orchestrator.py | ||