IdMappingRepository
Component Detail
Description
Persists and resolves the mapping between temporary client-generated offline IDs and the permanent server-assigned IDs returned after a mutation is confirmed. It ensures that subsequent local references and cross-entity relationships are transparently rewritten once the authoritative ID is known.
id-mapping-repository
Sources & reasoning
Lines 300-303 explicitly name the sync queue with retry/backoff and ID mapping as architectural components, which map directly to the BackgroundSyncWorker and SyncQueueService in the blueprint. Lines 50-54 reinforce that parallel operation during rollout requires the app's data to stay consistently synchronised with existing systems - silent background sync is the mechanism that makes this possible. The blueprint assigns MVP, consistent with offline-first being a launch-day architectural commitm
-
docs/source/likeperson.md · line 300-303Offline-first persistence (Drift + SQLCipher encrypted local DB, mutation outbox, sync queue with retry/backoff, ID mapping for offline-created entities, conflict resolver)
-
docs/source/likeperson.md · line 50-54Sterk enighet pÄ tvers: Eksisterende lÞsninger mÄ fungere parallelt til appen er godt etablert. Ingen av organisasjonene tÄler et hard-cut.
Responsibilities
- Store temporary-to-server ID pairs in a local SQLite table
- Look up the server ID for any given temporary ID during outbox processing
- Rewrite foreign-key references in queued mutations after an ID is resolved
- Expire and purge resolved mappings after a configurable retention window
- Expose a stream of newly resolved IDs for reactive UI updates
Interfaces
saveMappings(tempId: String, serverId: String): Future<void>
resolveId(tempId: String): String?
rewriteReferences(mutation: MutationRecord): MutationRecord
purgeExpired(): Future<void>
watchResolved(): Stream<IdMapping>
Related Data Entities (2)
Data entities managed by this component