ios - español - persistencia de datos en swift 4

¿Necesita un ManagedObjectContext principal de Core Data compartir un tipo de concurrencia con el contexto secundario?

Question

¿Puedo establecer el contexto principal de mi ManagedObjectContext en un ManagedObjectContext con un tipo de concurrencia diferente? Por ejemplo:

backgroundManagedObjectContext_ = [[NSManagedObjectContext alloc] initWithConcurrencyType:NSPrivateQueueConcurrencyType];
[backgroundManagedObjectContext_ setPersistentStoreCoordinator:coordinator];
managedObjectContext_ = [[NSManagedObjectContext alloc] initWithConcurrencyType:NSMainQueueConcurrencyType];
[managedObjectContext_ setParentContext:backgroundManagedObjectContext_];

Mi objetivo es (con suerte) obtener un ahorro rápido para managedObjectContext_ (ya que solo necesita guardar cosas en el contexto principal en memoria) y luego tener el backgroundManagedObjectContext_ hacer un guardado en su propia cola. A menos que necesite hacer otro guardado desde la cola de "primer plano" antes de que el fondo se guarde, mi usuario nunca debería ver tiempos de guardado prolongados.

Me encuentro con lo que parecen estancamientos, pero no estoy seguro si están relacionados con esto, o si mi problema está en otra parte.

Detalles para el único lugar donde puedo producir más o menos confiablemente el punto muerto:

Tengo un contexto de objeto gestionado para el hilo principal, está respaldado por un contexto de objeto gestionado con un tipo de concurrencia de cola privada, y ese tiene un almacén persistente.

Tengo un puñado de tipos de entidades (alrededor de 5), cada uno con una o dos relaciones bidireccionales con otra entidad.

Mi aplicación quiere usar iCloud (tengo ese código marcado para estas pruebas), por lo que no se puede enviar con una base de datos previamente poblada, necesita compilarla cuando detecta una vacía.

Así que cuando veo una base de datos vacía (esto está marcado en el hilo principal) agrego alrededor de 4 u 8 de todos menos uno de los tipos de entidades, y el último obtiene alrededor de 100 (todas las adiciones suceden en el hilo principal). El hilo principal tiene un saveContext. Una vez que se completa (sin errores), solicita al otro contexto de objeto gestionado que ejecute un bloque que también guarda un saveContext. Este saveContext es definitivamente un participante de punto muerto. Esto también es ÚNICAMENTE hecho con el NSManagedObjectContext "de fondo".

El flujo de control exacto es un poco turbio después de esto, como NSFetchedResultsController (todo un tipo de entidad dado (que tiene ~ 3 miembros) con un ordenamiento sencillo y un tamaño de lote de 20 o más) impulsa la siguiente ronda de actividad de Datos centrales , pero hay una llamada del TableViewController que pregunta cuántos elementos necesita administrar, que es "cuántos resultados tiene el controlador de resultados obtenidos". Esa llamada es el otro lado del punto muerto. (todo esto está en el hilo principal)

Answer 1

Desde mi experiencia, esto no es necesario siempre y cuando ambos contextos implementen el NSMainQueueConcurrencyType o el NSPrivateQueueConcurrencyType . Lo importante que debe recordarse es que cuando se interactúa con contextos de objetos administrados a través de múltiples hilos, todos los mensajes enviados al contexto se deben enviar a través de -performBlock: o performBlockAndWait:

En un proyecto reciente, tuve un NSManagedObjectContext principal que respaldaba un NSFetchedResultsController que se creó con NSMainQueueConcurrencyType . A partir de ahí, creé un NSManagedObjectContext con NSPrivateQueueConcurrencyType y establecí el contexto con NSMainQueueConcurrencyType como principal. Ahora, el contexto de mi hijo podría contener ediciones descartables al agregar un nuevo objeto que finalmente terminaría en la vista de tabla respaldada por NSFetchedResultsController respaldado por el contexto principal. Cuando estaba listo para guardar mis ediciones y pasarlas al contexto principal, el código se veía así.

// Save the child context first
[childContext performBlock:^{
NSError *error = nil;
[childContext save:&error];
// Save the changes on the main context
[parentContext performBlock:^{
NSError *parentError = nil;
[parentContext save:&parentError];
}];
}];

Ahora no puedo decir con certeza que esta es la forma correcta de hacerlo porque la documentación sobre esto es bastante escasa en este momento. Puede ser útil si puede mostrar algún código que cree que está causando puntos muertos. Si estás en el programa de desarrollo, es posible que desees consultar los videos de la sesión de la WWDC con respecto a los datos básicos de este año. Creo que hay dos, uno para Mac OS X y otro para iOS, que básicamente tocan las mismas ideas pero que también contienen información única.