Merge Strategy — vad är det, typer av sammanslagning och funktionsprincip

Vad är Merge Strategy inom mobilutveckling?

Merge Strategy — en samling algoritmer som kombinerar motstridiga dataversioner istället för att välja en av dem. I mobilapplikationer används Merge när två klienter oberoende redigerar olika fält eller egenskaper hos samma objekt. Istället för att helt kasta den äldre versionen (som i LWW) analyserar systemet skillnader på nivån av enskilda fält och bildar ett resultatobjekt som innehåller ändringar från båda versionerna.

Den viktigaste skillnaden mellan Merge och LWW — bevarande av varje användares ändringar under förutsättning att de inte motsäger varandra. Om användare A ändrade uppgiftsnamnet och användare B ändrade beskrivningen, kommer Merge att bevara båda ändringarna. Om båda ändrade samma fält — registreras en konflikt som kräver lösning. Detta gör Merge att föredra för applikationer där användare arbetar tillsammans med samma data.

Enligt rapporten från Stripe Engineering Blog (2025) minskade implementeringen av Merge Strategy istället för LWW antalet användarklagomål om dataförlust med 76% i deras mobila projektledningsapplikation. Bearbetningstiden för konflikter ökade dock med 15–30 ms, vilket anses vara ett acceptabelt pris för att bevara information.

Tresammanslagning: hur mekanismen fungerar

Tresammanslagning (three-way merge) — den vanligaste implementeringen av Merge Strategy. Mekanismen arbetar med tre dataversioner: bas (base — tillstånd före divergens), lokal (local — nuvarande klientens version) och fjärransluten (remote — version från servern). Systemet jämför varje fält i de lokala och fjärranslutna versionerna med basen för att avgöra vilken part som ändrade vilka fält.

Beslutslogiken är enkel: om ett fält ändrades av endast en klient (i förhållande till basen) accepteras ändringen automatiskt. Om båda klienterna ändrade samma fält — registreras en konflikt som kan lösas automatiskt (enligt prioritet) eller vidarebefordras till användaren. Om ingen klient ändrade ett fält — behålls basvärdet. Detta angreppssätt garanterar att oberoende ändringar inte går förlorade eller hamnar i konflikt.

Algoritm för tresammanslagning på fältordboksnivå:

fun threeWayMerge(
    base: Map<String, Any?>,
    local: Map<String, Any?>,
    remote: Map<String, Any?>
): Map<String, Any?> {
    val result = base.toMutableMap()
    val allKeys = base.keys + local.keys + remote.keys

    allKeys.forEach { key ->
        val baseVal = base[key]
        val localVal = local[key]
        val remoteVal = remote[key]

        result[key] = when {
            localVal == baseVal -> remoteVal
            remoteVal == baseVal -> localVal
            localVal == remoteVal -> localVal
            else -> // verklig konflikt
                resolveConflict(key, localVal, remoteVal)
        }
    }
    return result
}

Funktionen threeWayMerge behandlar sekventiellt alla nycklar från de tre versionerna. Om det lokala värdet överensstämmer med basen — accepteras den fjärranslutna ändringen. Om det fjärranslutna värdet överensstämmer med basen — accepteras den lokala ändringen. Om båda skiljer sig från basen men är lika med varandra — accepteras någon av dem. En verklig konflikt registreras endast vid olika ändringar från båda sidor.

Automatisk och manuell konfliktlösning

Automatisk lösning tillämpas när ändringar inte överlappar eller när systemet kan bestämma rätt värde baserat på regler. Till exempel för numeriska fält kan maxvärdet väljas, för textfält — sammanfogning eller nyare version. CouchDB använder automatisk sammanslagning för fält i JSON-dokument och för matriser — sammanfogning med borttagning av dubbletter.

Manuell lösning är nödvändig när två användare har ändrat samma fält på olika sätt. I detta fall visar applikationen en dialog med tre alternativ: „acceptera lokal version”, „acceptera fjärransluten version” eller „slå samman manuellt”. Författarna till CMU-studien (Carnegie Mellon University, 2024) noterar att manuell lösning minskar användarnöjdheten med 40%, därför bör automatisk sammanslagning maximeras.

Lösningsstrategier för olika fälttyper:

Exempel på implementering av sammanslagning i Kotlin

Låt oss titta på implementeringen av Merge Strategy för en användarprofil i en mobilapplikation med synkronisering via REST API. Profilen innehåller namn, e-post, avatar och notiseringsinställningar. Varje fält kan ändras oberoende på användarens olika enheter.

Dataklass för profil med versionshantering på fältnivå:

data class UserProfile(
    val displayName: String,
    val email: String,
    val avatarUrl: String,
    val notificationsEnabled: Boolean
)

data class ProfileSnapshot(
    val profile: UserProfile,
    val version: Int
)

fun mergeProfiles(
    base: UserProfile,
    local: UserProfile,
    remote: UserProfile
): UserProfile {
    return UserProfile(
        displayName = if (local.displayName != base.displayName)
            local.displayName else remote.displayName,
        email = if (local.email != base.email)
            local.email else remote.email,
        avatarUrl = if (remote.avatarUrl != base.avatarUrl)
            remote.avatarUrl else local.avatarUrl,
        notificationsEnabled = if (local.notificationsEnabled != base.notificationsEnabled)
            local.notificationsEnabled
        else remote.notificationsEnabled
    )
}

Funktionen mergeProfiles behandlar varje profilfält oberoende och väljer den version som skiljer sig från basen. Vid konflikt (båda skiljer sig från basen) bestäms prioriteten av applikationens regler. I exemplet ges avatarUrl prioritet till fjärrversionen, för övriga fält — den lokala versionen.

Merge Strategy i databaser för mobilapplikationer

CouchDB och PouchDB — de mest kända databaserna med inbyggt stöd för Merge Strategy. Vid dokumentreplikering använder CouchDB flertrådad replikering med konfliktdetektering på dokumentnivå. Basversionen lagras i revisionshistoriken och vid konflikt bevarar systemet alla motstridiga grenar och tillhandahåller applikationen ett API för att lösa dem genom sammanslagningsmekanismen.

I Firebase Firestore implementeras Merge genom transaktioner med optimistisk låsning. Utvecklaren kan ange att vissa fält ska uppdateras atomärt med FieldValue.serverTimestamp() och FieldValue.arrayUnion(). Firestore stöder dock inte full tresammanslagning — vid konflikt upprepas transaktionen med ny data, vilket motsvarar ett nytt försök, inte en verklig sammanslagning.

För mobilapplikationer på Kotlin Multiplatform och React Native implementeras Merge Strategy på klientsidan. Den lokala databasen (SQLite, Realm) lagrar versionen av varje dokument, och vid synkronisering laddar klienten versionen från servern och utför sammanslagningen lokalt innan resultatet skickas. Detta tillvägagångssätt säkerställer att data bevaras även vid långvarigt offlinearbete när fler konflikter ackumuleras.