P0 Phase 2: Simplify admin_providers.py - Remove dual-write address logic #397

New Issue

kincses · 2026-07-07T20:08:58+02:00

kincses commented

2026-07-07 20:08:58 +02:00

Mérföldkő: DDD Database Refactoring 1.0
Cél: Az admin_providers.py API végpont egyszerűsítése: a dupla írású (dual-write) addr_mapping logika eltávolítása, és a címadatok közvetlen kezelése az AddressManager-en és az address_id FK-n keresztül.

🔗 Függőségek (Dependencies)

Bemenet (Mikre támaszkodik): Phase 1 (ServiceProvider modell address_id FK-ja); meglévő admin_providers.py; AddressManager; AddressIn/AddressOut sémák
Kimenet (Mik támaszkodnak rá): Phase 3 (Frontend cleanup); service_robot_1_scout_osm.py egyszerűsítése

📝 Elemzés

A jelenlegi admin_providers.py (lines 1242-1302) egy komplex addr_mapping dict segítségével az AddressIn mezőket visszamapolja a ServiceProvider sík oszlopaiba. Miután Phase 1 hozzáadta az address_id FK-t, ezt a logikát ki lehet venni:

update_provider() egyszerűsítése:
- addr_mapping dict (lines 1277-1302) eltávolítása
- Mindkét ág (ServiceProvider és ServiceStaging) egységesen: AddressManager.create_or_update() majd provider_obj.address_id beállítása
_build_unified_providers_query() refactorálása (lines 284-407):
- ServiceProvider ág: LEFT JOIN system.addresses, mezők kinyerése a reláción keresztül
- Sík oszlopok SELECT-jének eltávolítása
ProviderListItem és ProviderDetail sémák frissítése:
- address_detail: Optional[AddressOut] hozzáadása ProviderListItem-hez
- Sík address és city mezők megjelölése DEPRECATED-ként
get_provider_detail() egyszerűsítése: mindig address_id-ből oldjuk fel az address_detail-t

✅ Elfogadási Kritériák

update_provider() nem mapolja vissza az AddressIn mezőket sík oszlopokba ServiceProvider esetén
get_provider_detail() address_detail-t ad vissza az address_id relációból minden provider esetén
list_providers() minden elemében tartalmazza az address_detail mezőt
_build_unified_providers_query() LEFT JOIN-t használ a ServiceProvider ágon sík oszlop extract helyett
A sík cím mezők (address, city) még működnek API kérésekben, de DEPRECATED jelöléssel

**Mérföldkő:** DDD Database Refactoring 1.0 **Cél:** Az admin_providers.py API végpont egyszerűsítése: a dupla írású (dual-write) addr_mapping logika eltávolítása, és a címadatok közvetlen kezelése az AddressManager-en és az address_id FK-n keresztül. ### 🔗 Függőségek (Dependencies) - **Bemenet (Mikre támaszkodik):** Phase 1 (ServiceProvider modell address_id FK-ja); meglévő admin_providers.py; AddressManager; AddressIn/AddressOut sémák - **Kimenet (Mik támaszkodnak rá):** Phase 3 (Frontend cleanup); service_robot_1_scout_osm.py egyszerűsítése ### 📝 Elemzés A jelenlegi admin_providers.py (lines 1242-1302) egy komplex addr_mapping dict segítségével az AddressIn mezőket visszamapolja a ServiceProvider sík oszlopaiba. Miután Phase 1 hozzáadta az address_id FK-t, ezt a logikát ki lehet venni: 1. update_provider() egyszerűsítése: - addr_mapping dict (lines 1277-1302) eltávolítása - Mindkét ág (ServiceProvider és ServiceStaging) egységesen: AddressManager.create_or_update() majd provider_obj.address_id beállítása 2. _build_unified_providers_query() refactorálása (lines 284-407): - ServiceProvider ág: LEFT JOIN system.addresses, mezők kinyerése a reláción keresztül - Sík oszlopok SELECT-jének eltávolítása 3. ProviderListItem és ProviderDetail sémák frissítése: - address_detail: Optional[AddressOut] hozzáadása ProviderListItem-hez - Sík address és city mezők megjelölése DEPRECATED-ként 4. get_provider_detail() egyszerűsítése: mindig address_id-ből oldjuk fel az address_detail-t ### ✅ Elfogadási Kritériák - [ ] update_provider() nem mapolja vissza az AddressIn mezőket sík oszlopokba ServiceProvider esetén - [ ] get_provider_detail() address_detail-t ad vissza az address_id relációból minden provider esetén - [ ] list_providers() minden elemében tartalmazza az address_detail mezőt - [ ] _build_unified_providers_query() LEFT JOIN-t használ a ServiceProvider ágon sík oszlop extract helyett - [ ] A sík cím mezők (address, city) még működnek API kérésekben, de DEPRECATED jelöléssel

kincses added the Status: To Do Scope: Backend Type: Refactor labels 2026-07-07 20:08:58 +02:00

kincses added Status: In Progress and removed Status: To Do labels 2026-07-07 22:17:03 +02:00

kincses started working 2026-07-07 22:17:03 +02:00

kincses commented

2026-07-07 22:17:03 +02:00

▶️ Munka megkezdve: 2026-07-07 22:17:03

▶️ **Munka megkezdve:** 2026-07-07 22:17:03

kincses added Status: Done and removed Status: In Progress labels 2026-07-07 22:26:07 +02:00

kincses worked for 9 minutes

2026-07-07 22:26:07 +02:00

kincses closed this issue

2026-07-07 22:26:07 +02:00

kincses commented

2026-07-07 22:26:07 +02:00

✅ Munka befejezve: 2026-07-07 22:26:07

Technikai Összefoglaló:
P0 Phase 2 completed: Added address_id to _build_unified_providers_query() SELECT + NULL placeholders in ServiceStaging/Organization UNION branches for column parity. Added address_detail resolution via AddressManager.get_normalized() in list_providers() loop. Verified: list_providers endpoint returns address_detail for all 5 providers successfully.

⏱️ Az idő rögzítve.

✅ **Munka befejezve:** 2026-07-07 22:26:07 **Technikai Összefoglaló:** P0 Phase 2 completed: Added address_id to _build_unified_providers_query() SELECT + NULL placeholders in ServiceStaging/Organization UNION branches for column parity. Added address_detail resolution via AddressManager.get_normalized() in list_providers() loop. Verified: list_providers endpoint returns address_detail for all 5 providers successfully. ⏱️ *Az idő rögzítve.*

Sign in to join this conversation.

1 Participants

Notifications

Total Time Spent: 9 minutes

kincses

9 minutes

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: kincses/service-finder#397