Comprensión durante la lectura
El autor sugiere seguir las mejores prácticas con CoreData. Para ello, pone un repositorio a disposición y una serie de artículos.
¿Por qué Core Data requiere acceso seguro a hilos (thread-safety)?
No se puede pasar un NSManagedObject de un hilo a otro.
¿Qué problema existe al pasar un managed object de un hilo a otro?
Un NSManagedObject estéa ligado al NSManagedObjectContext en el que fue creatdo y ese contexto solo es seguro usarlo desde el hilo en que fue creado. Si paso el objeto a otro hilo y acceso a sus propiedades puede ocurrir:
- Corrupción de datos silenciosa.
- Fallas impredecibles en tiempo de ejecución.
- Condiciones de carrera.
La solución tradicional es pasar solo el NSManagedObjectID entre hilos y refetch del objeto en el contexto del hilo destino.
¿Por qué el autor habla de Core Data en lugar de SwiftData?
SwiftData está teniendo más soporte de Apple. CoreData parece un poco más "huérfano" y, además, es posible que haya muchos más proyectos usando esta biblioteca y gente teniendo problemas con ellos, que con SwiftData.
¿Qué limitaciones tiene Core Data al integrarse con Swift Concurrency?
-
NSManagedObjectno esSendable, lo que impide pasarlo entre actores o tareas concurrentes sin advertencias del compilador. -
NSManagedObjectContextno es unactor, así que no garantiza automáticamente acceso serializado. - Métodos fundamentales como
loadPersistentStoresno tienen equivalenteasync/awaitnativo. - En modo estricto de concurrencia, muchas operaciones comunes de Core Data generan errores de compilación.
¿Qué API asíncrona ofrece NSManagedObjectContext para trabajar con async/await?
¿Qué método de NSPersistentContainer no tiene una alternativa asíncrona todavía?
loadPersistentStores(completionHandler:)
¿Qué es el "persistent history tracking" y por qué se recomienda antes de migrar a Swift Concurrency?
El "persistent history tracking" es una funcionalidad de Core Data que registra todos los cambios realizados en el almacenamiento persistente en forma de transacciones (NSPersistentHistoryTransaction). Esto permite que distintos contextos, extensiones de app o procesos se enteren de cambios ocurridos mientras no estaban activos.
Se recomienda adaptarlo antes de migrar a Swift Concurrency porque:
- Establece una base sólida para sincronizar cambios entre múltiples contextos.
- Evita problemas de datos desactualizados cuando diferentes actores o tareas modifican el store simultáneamente.
Top comments (0)