28 lines
1.8 KiB
Markdown
28 lines
1.8 KiB
Markdown
# Ka-Note Roadmap
|
|
|
|
## [LOW] Sync: Soft-delete Restrisiko bei neuem Gerät / DB-Reset
|
|
|
|
**Problem**
|
|
Wenn ein Gerät noch nie gepusht hat (neues Gerät oder IndexedDB gelöscht), ist `!local = true` für alle Pull-Einträge. Der Pull überschreibt dann keine lokale Version, sondern legt neu an — auch wenn der Eintrag auf einem anderen Gerät bereits gelöscht wurde. Das gelöschte Item erscheint wieder, bis das löschende Gerät seinen Push durchführt.
|
|
|
|
**Bereits gefixt**
|
|
- Push läuft jetzt vor Pull (`doSync`)
|
|
- Merge-Bedingung auf `>` statt `>=` (lokale Änderung gewinnt bei Versionsgleichstand)
|
|
|
|
**Restrisiko**
|
|
Szenario: Gerät A löscht Item (version N+1), hat aber noch nie gepusht. Gerät B macht Full-Sync: Pull bringt Server-Version N (nicht gelöscht), `!local` → wird eingespielt. Gerät B sieht das Item als vorhanden.
|
|
|
|
**Lösungsoptionen**
|
|
|
|
1. **Serverseitig: `deletedAt`-Items aus Pull-Response ausfiltern**
|
|
Server gibt bei Pull keine soft-deleted Items zurück. Gerät B bekommt das Item gar nicht erst. Problem: Wenn Gerät B das Item schon lokal hat (z.B. eigene ältere Version), wird es nie als gelöscht markiert.
|
|
|
|
2. **Tombstone-Tabelle**
|
|
Separate Tabelle `deletions(entityId, deletedAt, version)` — wird immer mitübertragen. Client wertet Tombstones aus und löscht lokale Items explizit. Robusteste Lösung, erhöht aber Komplexität.
|
|
|
|
3. **Server filtert + Client löscht lokale Einträge die der Server nicht mehr liefert**
|
|
Server sendet nur aktive Items. Client vergleicht lokale IDs mit Pull-Response und markiert fehlende als `deletedAt`. Einfacher als Tombstones, aber fehleranfällig bei partiellen Pulls (since-Filter).
|
|
|
|
**Empfehlung**
|
|
Option 2 (Tombstones) für korrekte Multi-Gerät-Unterstützung. Option 3 als pragmatischer Zwischenschritt wenn Full-Sync (since=null) garantiert ist.
|