Merge Strategy — یہ کیا ہے، انضمام کی اقسام اور کام کا اصول

موبائل ڈویلپمنٹ میں Merge Strategy کیا ہے؟

Merge Strategy الگورتھم کا ایک مجموعہ ہے جو متضاد ڈیٹا ورژنز میں سے کسی ایک کو منتخب کرنے کے بجائے انہیں اکٹھا کرتا ہے۔ موبائل ایپلیکیشنز میں، انضمام اس وقت استعمال ہوتا ہے جب دو کلائنٹ آزادانہ طور پر ایک ہی آبجیکٹ کے مختلف فیلڈز یا خصوصیات میں ترمیم کرتے ہیں۔ پرانے ورژن کو مکمل طور پر رد کرنے کے بجائے (جیسا کہ LWW میں)، نظام انفرادی فیلڈ کی سطح پر فرق کا تجزیہ کرتا ہے اور دونوں ورژنز سے تبدیلیوں پر مشتمل ایک نتیجہ خیز آبجیکٹ تیار کرتا ہے۔

اہم فرق انضمام اور LWW کے درمیان یہ ہے کہ یہ ہر صارف کی تبدیلیوں کو محفوظ رکھتا ہے بشرطیکہ وہ ایک دوسرے سے متصادم نہ ہوں۔ اگر صارف A نے کام کا نام تبدیل کیا اور صارف B نے تفصیل تبدیل کی، تو انضمام دونوں تبدیلیوں کو محفوظ رکھتا ہے۔ اگر دونوں نے ایک ہی فیلڈ تبدیل کیا — ایک تنازع ریکارڈ کیا جاتا ہے جسے حل کرنے کی ضرورت ہے۔ یہ انضمام کو ان ایپلیکیشنز کے لیے ترجیحی بناتا ہے جہاں صارف ایک ہی ڈیٹا پر مشترکہ طور پر کام کرتے ہیں۔

Stripe Engineering Blog (2025) کی ایک رپورٹ کے مطابق، LWW کے بجائے Merge Strategy لاگو کرنے سے ان کی موبائل پروجیکٹ مینجمنٹ ایپلیکیشن میں ڈیٹا کے نقصان کے بارے میں صارفین کی شکایات میں 76% کمی آئی۔ تاہم، تنازعات کی کارروائی کا وقت 15–30 ms بڑھ گیا، جسے ڈیٹا کی سالمیت کے لیے قابل قبول قیمت سمجھا جاتا ہے۔

تین طرفہ انضمام: طریقہ کار کیسے کام کرتا ہے

تین طرفہ انضمام (three-way merge) Merge Strategy کا سب سے عام نفاذ ہے۔ یہ طریقہ کار ڈیٹا کے تین ورژنز کے ساتھ کام کرتا ہے: بنیادی (انحراف سے پہلے کی حالت)، مقامی (موجودہ کلائنٹ کا ورژن) اور دور دراز (سرور ورژن)۔ نظام مقامی اور دور دراز ورژنز کے ہر فیلڈ کا بنیادی سے موازنہ کرتا ہے تاکہ یہ تعین کیا جا سکے کہ کس طرف نے کون سے فیلڈز تبدیل کیے۔

فیصلہ منطق سادہ ہے: اگر صرف ایک کلائنٹ نے فیلڈ تبدیل کیا (بنیادی کے نسبت)، اس کی تبدیلی خود بخود قبول کر لی جاتی ہے۔ اگر دونوں کلائنٹ نے ایک ہی فیلڈ تبدیل کیا — ایک تنازع ریکارڈ کیا جاتا ہے جسے خود بخود (ترجیح کے مطابق) حل کیا جا سکتا ہے یا صارف کو سونپا جا سکتا ہے۔ اگر کسی کلائنٹ نے فیلڈ تبدیل نہیں کیا — بنیادی قیمت برقرار رہتی ہے۔ یہ نقطہ نظر اس بات کی ضمانت دیتا ہے کہ آزاد تبدیلیاں نہ تو کھوتی ہیں اور نہ ہی متصادم ہوتی ہیں۔

فیلڈ ڈکشنری کی سطح پر تین طرفہ انضمام الگورتھم:

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 -> // real conflict
                resolveConflict(key, localVal, remoteVal)
        }
    }
    return result
}

threeWayMerge فنکشن تینوں ورژنز کی تمام کنجیوں کو ترتیب وار پروسیس کرتا ہے۔ اگر مقامی قیمت بنیادی سے مماثل ہو — دور دراز کی تبدیلی قبول کی جاتی ہے۔ اگر دور دراز بنیادی سے مماثل ہو — مقامی تبدیلی قبول کی جاتی ہے۔ اگر دونوں بنیادی سے مختلف ہوں لیکن ایک دوسرے کے برابر ہوں — کوئی بھی قبول کر لیا جاتا ہے۔ ایک حقیقی تنازع صرف اس وقت ریکارڈ کیا جاتا ہے جب دونوں طرف مختلف تبدیلیاں ہوں۔

خودکار اور دستی تنازعات کا حل

خودکار حل اس وقت لاگو کیا جاتا ہے جب تبدیلیاں اوورلیپ نہ ہوں یا جب نظام قواعد کی بنیاد پر صحیح قیمت کا تعین کر سکے۔ مثال کے طور پر، عددی فیلڈز کے لیے زیادہ سے زیادہ قیمت منتخب کی جا سکتی ہے، متن کے فیلڈز کے لیے — concatenation یا نیا ورژن۔ CouchDB JSON دستاویز کے فیلڈز کے لیے خودکار انضمام استعمال کرتا ہے، اور arrays کے لیے — نقلوں کو ہٹانے کے ساتھ concatenation۔

دستی حل اس وقت ضروری ہے جب دو صارفین نے ایک ہی فیلڈ کو مختلف طریقے سے تبدیل کیا ہو۔ اس صورت میں، ایپلیکیشن تین آپشنز کے ساتھ ایک ڈائیلاگ دکھاتی ہے: \u201cمقامی ورژن قبول کریں\u201d، \u201cدور دراز ورژن قبول کریں\u201d یا \u201cدستی طور پر ضم کریں\u201d۔ CMU (کارنیگی میلن یونیورسٹی، 2024) کی تحقیق کے مطابق، دستی حل صارف کی اطمینان کو 40% کم کر دیتا ہے، لہذا خودکار انضمام کو زیادہ سے زیادہ کیا جانا چاہیے۔

مختلف فیلڈ اقسام کے لیے حل کی حکمت عملیاں:

Kotlin میں انضمام کی مثالیں

نفاذ پر غور کریں REST API کے ذریعے ہم آہنگی کے ساتھ موبائل ایپلیکیشن میں صارف پروفائل کے لیے Merge Strategy۔ پروفائل میں نام، ای میل، اوتار اور اطلاع کی ترتیبات شامل ہیں۔ ہر فیلڈ صارف کے مختلف آلات پر آزادانہ طور پر تبدیل کیا جا سکتا ہے۔

فیلڈ سطح کی ورژننگ کے ساتھ پروفائل ڈیٹا کلاس:

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
    )
}

mergeProfiles فنکشن پروفائل کے ہر فیلڈ کو آزادانہ طور پر پروسیس کرتا ہے، اس ورژن کو منتخب کرتا ہے جو بنیادی سے مختلف ہے۔ تنازع کی صورت میں (دونوں بنیادی سے مختلف)، ترجیح ایپلیکیشن کے قواعد کے مطابق متعین کی جاتی ہے۔ مثال میں، avatarUrl کے لیے دور دراز ورژن کو ترجیح دی جاتی ہے، باقی فیلڈز کے لیے — مقامی ورژن کو۔

موبائل ایپ ڈیٹا بیسز میں Merge Strategy

CouchDB اور PouchDB سب سے مشہور ڈیٹا بیس ہیں جن میں بلٹ ان Merge Strategy سپورٹ ہے۔ دستاویز کی نقل کے دوران، CouchDB دستاویز کی سطح پر تنازعات کا پتہ لگانے کے ساتھ ملٹی تھریڈڈ نقل استعمال کرتا ہے۔ بنیادی ورژن نظر ثانی کی تاریخ میں محفوظ کیا جاتا ہے، اور تنازع کی صورت میں، نظام تمام متضاد شاخوں کو محفوظ رکھتا ہے اور ایپلیکیشن کو انضمام کے طریقہ کار کے ذریعے انہیں حل کرنے کے لیے API فراہم کرتا ہے۔

Firebase Firestore میں، انضمام پرامید لاکنگ کے ساتھ لین دین کے ذریعے لاگو کیا جاتا ہے۔ ڈویلپر بتا سکتا ہے کہ کچھ فیلڈز کو FieldValue.serverTimestamp() اور FieldValue.arrayUnion() استعمال کرتے ہوئے ایٹمically اپ ڈیٹ کیا جانا چاہیے۔ تاہم، Firestore مکمل تین طرفہ انضمام کی حمایت نہیں کرتا — تنازع کی صورت میں، لین دین نئے ڈیٹا کے ساتھ دوبارہ کوشش کی جاتی ہے، جو حقیقی انضمام کے بجائے دوبارہ کوشش کے برابر ہے۔

Kotlin Multiplatform اور React Native پر موبائل ایپلیکیشنز کے لیے، Merge Strategy کلائنٹ کی طرف لاگو کیا جاتا ہے۔ مقامی ڈیٹا بیس (SQLite, Realm) ہر دستاویز کا ورژن محفوظ کرتا ہے، اور ہم آہنگی کے دوران، کلائنٹ سرور ورژن لوڈ کرتا ہے اور نتیجہ بھیجنے سے پہلے مقامی طور پر انضمام کرتا ہے۔ یہ نقطہ نظر طویل آف لائن آپریشن کے دوران بھی ڈیٹا کی سالمیت کو یقینی بناتا ہے جب مزید تنازعات جمع ہوتے ہیں۔