Core Data — یہ کیا ہے، ڈیٹا ماڈل اور یہ کیسے کام کرتا ہے

Core Data کیا ہے اور iOS میں اس کا کردار

Core Data ایک آبجیکٹ گراف اور مستقل مینجمنٹ فریم ورک ہے جو Cocoa Touch کا حصہ ہے۔ عام غلط فہمی کے برعکس، Core Data ڈیٹا بیس نہیں ہے، بلکہ ایک آبجیکٹ مینجمنٹ پرت ہے جو SQLite کو اپنے اسٹور میں سے ایک کے طور پر استعمال کر سکتی ہے۔ Core Data کا بنیادی کام آبجیکٹ کی تبدیلیوں کو ٹریک کرنا، ان کے لائف سائیکل کا انتظام کرنا اور ڈسک کے ساتھ حالت کو ہم آہنگ کرنا ہے۔

فریم ورک ایک آبجیکٹ گراف فراہم کرتا ہے جہاں ہر Managed Object کو سیاق و سباق کے ذریعے تبدیلیوں کے لیے ٹریک کیا جاتا ہے۔ محفوظ کرنے پر، تمام تبدیل شدہ، شامل اور حذف کردہ آبجیکٹ ایک ہی لین دین میں مستقل اسٹور میں جمع ہو جاتے ہیں۔ یہ ڈویلپر کو SQL استفسارات لکھنے اور دستی طور پر لین دین کے انتظام کی ضرورت کو ختم کرتا ہے۔

Swift Developer Survey (2025) کے اعدادوشمار کے مطابق، Core Data مقامی ڈیٹا کے ساتھ کام کرنے والی 52% iOS ایپلیکیشنز میں استعمال ہوتا ہے۔ جدید متبادل (SwiftData، Realm) کے ظہور کے باوجود، Core Data اپنی پختگی اور گہرے نظام انضمام کی وجہ سے موجودہ Apple پروجیکٹس میں بنیادی فریم ورک بنا ہوا ہے۔

Core Data کو درمیانی پیچیدگی کے ڈیٹا ماڈل والے پروجیکٹس کے لیے استعمال کریں، جہاں آبجیکٹ کے تعلقات، تبدیلیوں کو واپس لینے اور فالٹنگ میکانزم کے ذریعے خودکار کیشنگ کی ضرورت ہو۔

Core Data آرکیٹیکچر Managed Object Context کے تصور کے گرد بنایا گیا ہے — ایک ورک اسپیس جو تمام آبجیکٹ کی تبدیلیوں کو ٹریک کرتا ہے۔ سیاق و سباق بلٹ ان NSUndoManager کے ذریعے واپس لینے/دوبارہ کرنے کی حمایت کرتا ہے، جو دستی طور پر اسٹیٹ سنیپ شاٹس محفوظ کیے بغیر ڈرافٹ اور کارروائی کی منسوخی کو نافذ کرنے کی اجازت دیتا ہے۔ save() کال کرنے پر، سیاق و سباق تمام تبدیلیوں کو ایک ہی لین دین میں مستقل اسٹور میں جمع کرتا ہے، ڈیٹا کی ایٹمیت اور مستقل مزاجی کو یقینی بناتا ہے۔

ڈیٹا ماڈل: Entity، Attributes، Relationships

Core Data ڈیٹا ماڈل .xcdatamodeld فائل میں بیان کیا جاتا ہے — Xcode کا بصری ایڈیٹر جہاں تمام Entity، ان کی خصوصیات اور تعلقات بیان کیے جاتے ہیں۔ تالیف کے وقت، ماڈل .momd میں ترتیب پاتا ہے اور NSManagedObjectModel کے ذریعے لوڈ ہوتا ہے۔

Entity اور Attributes

Entity ڈیٹا کی قسم کی تفصیل ہے، جو SQL میں جدول کے مشابہ ہے۔ ہر Entity میں Attributes کا ایک سیٹ ہوتا ہے — ڈیٹا کی قسم (String، Integer، Date، Boolean، Data) والے نام والے فیلڈز۔ Room کے برعکس، Core Data کو ماڈل ایڈیٹر کے ذریعے ہر وصف کے لیے واضح قسم کے انتخاب کی ضرورت ہوتی ہے۔

Relationships

Relationship Entity کے درمیان ایک کنکشن ہے، جو SQL میں غیر ملکی کلید کے مشابہ ہے۔ Core Data تمام قسم کے تعلقات کی حمایت کرتا ہے: ایک سے ایک، ایک سے کئی اور کئی سے کئی۔ ہر رشتے کے لیے Delete Rule (Cascade، Nullify، Deny) ترتیب دیا جاتا ہے — متعلقہ آبجیکٹ کو حذف کرنے پر رویہ۔

Delete Rule کا انتخاب ڈیٹا کی سالمیت کے لیے اہم ہے: Cascade تصدیق کے بغیر ڈیٹا بیس کا ایک تہائی حصہ حذف کر سکتا ہے، جبکہ Deny غیر واضح غلطی کے ساتھ آپریشن کو روک سکتا ہے۔ پروڈکشن کوڈ میں، دستی یتیم ریکارڈ ہینڈلنگ کے ساتھ Nullify کی سفارش کی جاتی ہے۔

Xcode ماڈل ایڈیٹر میں، ڈویلپر نہ صرف Entity اور خصوصیات بلکہ constraints (منفرد رکاوٹیں)، استفسار کو تیز کرنے کے لیے انڈیکس اور خصوصیات کے لیے ڈیفالٹ اقدار بھی بیان کر سکتا ہے۔ تمام ماڈل تبدیلیاں .momd فائل میں مرتب ہوتی ہیں، جو NSPersistentContainer کی ابتدا کے دوران لوڈ ہوتی ہے۔ ماڈل ورژننگ (Model Versioning) متعدد اسکیما ورژنز کو برقرار رکھنے اور ان کے درمیان منتقلی کرنے کی اجازت دیتا ہے۔

Core Data اسٹیک: PersistentContainer اور Context

NSPersistentContainer ایک واحد آبجیکٹ ہے جو iOS 10 اور macOS 10.12 سے Core Data اسٹیک کا انتظام کرتا ہے۔ یہ NSManagedObjectModel، NSPersistentStoreCoordinator اور NSManagedObjectContext کو سمیٹتا ہے، ماڈل لوڈنگ اور اسٹور کنفیگریشن کو خودکار بناتا ہے۔ پرانے ورژنز کے لیے، اسٹیک دستی طور پر بنایا جاتا تھا، لیکن اب اس کی سفارش نہیں کی جاتی۔

let container = NSPersistentContainer(name: "DataModel")
container.loadPersistentStores { _, error in
    if let error { fatalError("Core Data load failed: \(error)") }
}
let context = container.viewContext

viewContext مرکزی تھریڈ سے منسلک اہم سیاق ہے۔ تمام پڑھنے اور UI اپ ڈیٹس اس کے ذریعے کیے جاتے ہیں۔ کارکردگی کے لیے، بعد میں ہم آہنگی کے ساتھ پس منظر کے چائلڈ سیاق میں ڈیٹا لکھنے کی سفارش کی جاتی ہے۔

NSPersistentStoreCoordinator

NSPersistentStoreCoordinator کوآرڈینیٹر ماڈل کو ڈسک پر فزیکل اسٹوریج سے جوڑتا ہے۔ Core Data کئی اسٹور اقسام کی حمایت کرتا ہے: SQLite (سفارش کردہ)، Binary اور In-Memory۔ SQLite اسٹور منتقلی، بڑھتی ہوئی بیک اپ اور لکھنے کے آپریشنز کے دوران کریش مزاحمت کی حمایت کرتا ہے۔

NSFetchRequest اور ڈیٹا کے ساتھ کام

NSFetchRequest ایک آبجیکٹ ہے جو Core Data اسٹور سے استفسار کو بیان کرتا ہے۔ اس میں Entity کا نام، فلٹر predicate، ترتیب دینے والے descriptors اور fetch ترتیبات شامل ہیں۔ استفسار context.fetch() کے ذریعے عمل میں آتا ہے، جو NSManagedObject کی ایک صف لوٹاتا ہے۔

let request = NSFetchRequest<User>(entityName: "User")
request.predicate = NSPredicate(format: "age >= %d", 18)
request.sortDescriptors = [NSSortDescriptor(key: "name", ascending: true)]
request.fetchLimit = 50

let results = try context.fetch(request)

NSPredicate پیچیدہ شرائط کی حمایت کرتا ہے: LIKE، IN، BETWEEN، CONTAINS[c] (کیس غیر حساس)، متعلقہ Entity پر نیسٹڈ استفسار کے لیے SUBQUERY۔ Core Data NSFetchedResultsController کی بھی حمایت کرتا ہے — UITableView میں رد عمل ڈیٹا لوڈنگ کے لیے ایک کلاس، جو خود بخود تبدیلیوں کو ٹریک کرتی ہے اور متحرک حصوں کے ساتھ ٹیبل کو اپ ڈیٹ کرتی ہے۔

ملٹی تھریڈڈ ماحول میں Core Data

ملٹی تھریڈڈ ایپلیکیشن میں Core Data کے ساتھ کام کرنے کے لیے سخت قوانین کی پابندی ضروری ہے: NSManagedObject کو براہ راست تھریڈز کے درمیان منتقل نہیں کیا جا سکتا۔ ہر تھریڈ (یا قطار) کو اپنا سیاق استعمال کرنا چاہیے۔ بنیادی طریقہ لکھنے کے لیے نجی قطار (NSPrivateQueueConcurrencyType) کے ساتھ چائلڈ NSManagedObjectContext اور پڑھنے کے لیے viewContext بنانا ہے۔

چائلڈ سیاق پیرنٹ میں محفوظ کرتا ہے، اور پھر پیرنٹ ڈسک اسٹور میں محفوظ کرتا ہے۔ یہ ضمانت دیتا ہے کہ تبدیلیاں مرکزی تھریڈ کو مسدود نہیں کرتیں اور UI ہمیشہ mergeChanges یا محفوظ کرنے پر خودکار viewContext اپ ڈیٹ کے ذریعے ایک مستقل حالت دیکھتا ہے۔

Core Data faulting استعمال کرتا ہے — متعلقہ آبجیکٹس کے لیے تاخیری لوڈنگ میکانزم۔ صارف کے پتے طلب کیے بغیر User کو حاصل کرتے وقت، متعلقہ Address آبجیکٹ اس وقت تک لوڈ نہیں ہوتے جب تک ڈاٹ نوٹیشن کے ذریعے ان تک رسائی نہ کی جائے۔ Faulting میموری بچاتا ہے اور لوڈنگ کو تیز کرتا ہے، لیکن پس منظر کے سیاق میں رسائی کو کنٹرول نہ کرنے پر مرکزی تھریڈ پر غیر متوقع ڈسک رسائی کا سبب بن سکتا ہے۔

موثر ملٹی تھریڈنگ کے لیے، میموری میں آبجیکٹ لوڈ کیے بغیر بلک اندراج اور حذف کرنے کے لیے NSBatchInsertRequest اور NSBatchDeleteRequest استعمال کریں — یہ سرور کے ساتھ ڈیٹا سنکرونائزیشن کے لیے اہم ہے۔

بیچ آپریشنز سیاق اور آبجیکٹ گراف کو نظرانداز کرتے ہوئے براہ راست NSPersistentStoreCoordinator سطح پر عمل میں آتے ہیں۔ یہ میموری میں 10,000 NSManagedObject مثالیں بنائے بغیر ملی سیکنڈز میں 10,000 ریکارڈ داخل کرنے کی اجازت دیتا ہے۔ بیچ درخواست پر عمل کرنے کے بعد، UI میں نئے ڈیٹا کی عکاسی کرنے کے لیے mergeChangesFromContextDidSaveNotification کے ذریعے سیاق کو اپ ڈیٹ کرنا ضروری ہے۔ Apple ابتدائی ڈیٹا لوڈنگ اور رات بھر سرور سنکرونائزیشن کے لیے بیچ آپریشنز کی سفارش کرتا ہے۔

Core Data میں تبدیلی کی ٹریکنگ کے لیے NSPersistentHistoryTracking استعمال کیا جاتا ہے — ایک میکانزم جو ہر لین دین (اندراج، اپ ڈیٹ، حذف) کو علیحدہ تاریخ میں ریکارڈ کرتا ہے۔ ہسٹری ٹریکنگ کو فعال کرنے سے ایک ہی SQLite فائل کے ساتھ کام کرنے والے مختلف عملوں اور ایپلیکیشنز (مثال کے طور پر مرکزی ایپلیکیشن اور Notification Service Extension) کے درمیان ڈیٹا سنکرونائزیشن ممکن ہوتی ہے۔ ایکٹیویشن persistentHistoryTrackingKey پرچم کے ساتھ NSPersistentStoreDescription کے ذریعے کی جاتی ہے، اور پڑھنا تاریخ اور لین دین کی قسم کے مطابق فلٹر کرنے والے NSPersistentHistoryChangeRequest کے ذریعے کیا جاتا ہے۔

Core Data ڈیبگنگ اور کارکردگی پروفائلنگ کے لیے macOS پر Xcode میں Instruments سوٹ سے Core Data Profiler ٹول استعمال کیا جاتا ہے۔ یہ ہر آپریشن کی مدت اور ٹیبلز اور ٹائم لائن گرافس میں لوڈ کردہ آبجیکٹس کی تعداد کے ساتھ تمام fetch، insert، delete اور save آپریشنز دکھاتا ہے۔ ڈویلپر مسئلہ والے علاقوں کی نشاندہی کر سکتا ہے: ایک ہی استفسار کے متعدد fetch (کیشنگ کی کمی)، ٹیبل اسکرول کرتے وقت fault آبجیکٹ لیک یا متعلقہ ہستیوں کی ہم وقت ساز لوڈنگ کی وجہ سے مرکزی تھریڈ کی رکاوٹ۔ سمیلیٹر کی کارکردگی iPhone یا iPad پر ایپلیکیشن کے حقیقی رویے کی عکاسی نہیں کرتی، لہذا سمیلیٹر کے بجائے حقیقی ڈیوائس پر پروفائلنگ چلانے کی سفارش کی جاتی ہے۔