P0 Phase 1: Add address_id FK to ServiceProvider + Data Migration #396

New Issue

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

kincses commented

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

Mérföldkő: DDD Database Refactoring 1.0
Cél: Hozzáadni az address_id UUID idegen kulcsot a marketplace.service_providers táblához, majd a meglévő, sík oszlopokban tárolt címadatokat áttelepíteni a központi system.addresses táblába.

🔗 Függőségek (Dependencies)

Bemenet (Mikre támaszkodik): Meglévő marketplace.service_providers tábla sík cím oszlopai (city, address_zip, address_street_name, address_street_type, address_house_number); AddressManager szolgáltatás; system.addresses tábla; AddressIn séma
Kimenet (Mik támaszkodnak rá): Phase 2 (Backend API refactor); Phase 3 (Frontend cleanup); admin_providers.py egyszerűsítése

📝 Elemzés

A ServiceProvider modell (social.py:23) az egyetlen olyan entitás a rendszerben, amelyik MÉG NEM használ address_id UUID FK-t a system.addresses táblához. Ehelyett 5 darab sík oszlopban (city, address_zip, address_street_name, address_street_type, address_house_number) tárolja a címadatokat. A Phase 1 feladata:

address_id UUID FK oszlop hozzáadása a ServiceProvider modellhez (SQLAlchemy)
address kapcsolat (relationship) definiálása lazy=selectin betöltéssel
Adatmigrációs szkript írása, amely:
- Végigiterál minden ServiceProvider rekordon, ahol van sík címadat
- AddressManager.create_or_update() segítségével létrehozza a megfelelő system.addresses rekordot
- Beállítja a service_providers.address_id mezőt az új UUID-re
sync_engine.py futtatása a séma konzisztencia ellenőrzéséhez
Verifikáció: service_providers tábla lekérdezése, hogy minden rekordhoz tartozik address_id

✅ Elfogadási Kritériák

marketplace.service_providers tábla rendelkezik address_id UUID FK-val → system.addresses.id
Minden meglévő ServiceProvider rekord (sík címmel) rendelkezik megfelelő system.addresses rekorddal, linked via address_id
A ServiceProvider modell tartalmazza az address relationship-et lazy=selectin-nel
A sync_engine.py nem jelez sémabeli eltérést
A visszamenőleges kompatibilitás biztosított (a sík oszlopok még a helyükön maradnak)

**Mérföldkő:** DDD Database Refactoring 1.0 **Cél:** Hozzáadni az `address_id` UUID idegen kulcsot a marketplace.service_providers táblához, majd a meglévő, sík oszlopokban tárolt címadatokat áttelepíteni a központi system.addresses táblába. ### 🔗 Függőségek (Dependencies) - **Bemenet (Mikre támaszkodik):** Meglévő marketplace.service_providers tábla sík cím oszlopai (city, address_zip, address_street_name, address_street_type, address_house_number); AddressManager szolgáltatás; system.addresses tábla; AddressIn séma - **Kimenet (Mik támaszkodnak rá):** Phase 2 (Backend API refactor); Phase 3 (Frontend cleanup); admin_providers.py egyszerűsítése ### 📝 Elemzés A ServiceProvider modell (social.py:23) az egyetlen olyan entitás a rendszerben, amelyik MÉG NEM használ address_id UUID FK-t a system.addresses táblához. Ehelyett 5 darab sík oszlopban (city, address_zip, address_street_name, address_street_type, address_house_number) tárolja a címadatokat. A Phase 1 feladata: 1. address_id UUID FK oszlop hozzáadása a ServiceProvider modellhez (SQLAlchemy) 2. address kapcsolat (relationship) definiálása lazy=selectin betöltéssel 3. Adatmigrációs szkript írása, amely: - Végigiterál minden ServiceProvider rekordon, ahol van sík címadat - AddressManager.create_or_update() segítségével létrehozza a megfelelő system.addresses rekordot - Beállítja a service_providers.address_id mezőt az új UUID-re 4. sync_engine.py futtatása a séma konzisztencia ellenőrzéséhez 5. Verifikáció: service_providers tábla lekérdezése, hogy minden rekordhoz tartozik address_id ### ✅ Elfogadási Kritériák - [ ] marketplace.service_providers tábla rendelkezik address_id UUID FK-val → system.addresses.id - [ ] Minden meglévő ServiceProvider rekord (sík címmel) rendelkezik megfelelő system.addresses rekorddal, linked via address_id - [ ] A ServiceProvider modell tartalmazza az address relationship-et lazy=selectin-nel - [ ] A sync_engine.py nem jelez sémabeli eltérést - [ ] A visszamenőleges kompatibilitás biztosított (a sík oszlopok még a helyükön maradnak)

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

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

kincses started working 2026-07-07 22:15:57 +02:00

kincses commented

2026-07-07 22:15:57 +02:00

▶️ Munka megkezdve: 2026-07-07 22:15:57

▶️ **Munka megkezdve:** 2026-07-07 22:15:57

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

kincses worked for 1 minute

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

kincses closed this issue

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

kincses commented

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

✅ Munka befejezve: 2026-07-07 22:16:59

Technikai Összefoglaló:
✅ Phase 1 complete: address_id FK already exists in ServiceProvider model and database. All 7 providers have address_id set with corresponding system.addresses records. sync_engine confirms 1282 OK, 0 drift.

⏱️ Az idő rögzítve.

✅ **Munka befejezve:** 2026-07-07 22:16:59 **Technikai Összefoglaló:** ✅ Phase 1 complete: address_id FK already exists in ServiceProvider model and database. All 7 providers have address_id set with corresponding system.addresses records. sync_engine confirms 1282 OK, 0 drift. ⏱️ *Az idő rögzítve.*

Sign in to join this conversation.

1 Participants

Notifications

Total Time Spent: 1 minute

kincses

1 minute

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: kincses/service-finder#396