3. Teori: Arsitektur Internal SwiftData

Layer Stack

swift
SwiftData API (@Model, @Query, ModelContext)
          ↓
   PersistentModel Protocol
   (generated by @Model macro)
          ↓
   ModelContext (unit of work, change tracking)
          ↓
   ModelContainer (schema + configuration)
          ↓
   NSPersistentContainer / NSPersistentStoreCoordinator
   (Core Data underneath)
          ↓
   SQLite / CloudKit store

SwiftData adalah wrapper modern di atas Core Data — bukan rewrite dari nol. Ini berarti:

Semua limitasi Core Data (tidak ada set operasi, tidak ada raw SQL, store tunggal per entity) tetap berlaku
Performa karakteristik Core Data (lazy fault, row cache, batch fetch) juga berlaku
Bisa interop dengan Core Data jika dibutuhkan

ModelContext sebagai Unit of Work

ModelContext mengimplementasikan Unit of Work pattern:

swift
Fetch → objek masuk "identity map" context
Mutate → perubahan dicatat di change buffer
save() → flush semua perubahan ke persistent store
rollback() / context deinit → buang semua perubahan

Satu model instance hanya boleh hidup di satu context. Passing instance antar context (misal: background → main) adalah data race — gunakan PersistentIdentifier sebagai jembatan.

Faulting: Lazy Loading per Default

swift
// SwiftData (seperti Core Data) menggunakan "fault" untuk relasi:
let post = try context.fetch(FetchDescriptor<Post>()).first!

// post.author belum di-load sampai kamu akses:
print(post.author.name)  // ← DI SINI baru fetch author dari SQLite (fault fires)

// Untuk query yang akan akses banyak relasi, lebih efisien prefetch:
var descriptor = FetchDescriptor<Post>()
descriptor.relationshipKeyPathsForPrefetching = [\.author, \.tags]
// Satu query JOIN daripada N+1 queries