2012-09-19 18 views
9

Mi comprensión de la documentación y de this answer es que si existen los datos, existingObjectWithID:error: y objectWithID: métodos de NSManagedObjectContext deben devolver el mismo objeto, pero cuando los datos doesn' t existe, existingObjectWithID:error: devolverá nil, mientras que objectWithID: devolverá un objeto que tiene fallas en lugar de datos.existingObjectWithID: error: devuelve nil, pero objectWithID: devuelve un objeto utilizable real

Lo que estoy viendo en una aplicación es una instancia donde (después de crear el objeto en un hilo de fondo dentro de un contexto de objeto administrado y guardado, ir al hilo principal, guardar y traer el ID de objeto del contexto secundario al contexto del objeto primario), existingObjectWithID:error: devuelve nil, pero objectWithID: devuelve un objeto real utilizable con datos válidos, no fallas.

¿Es incorrecto mi entendimiento de los dos métodos? ¿Estoy haciendo algo mal?

(Quiero que el comportamiento VUELTA a nil -cuando-HAY-no-datos de existingObjectWithID:error:, pero la incapacidad para obtener los datos de los objetos de nueva creación es problemática.)


edición: Supongo que podría usar objectWithID:, luego probar inmediatamente el acceso a una propiedad del objeto devuelto dentro de un bloque try-catch, capturar la excepción lanzada y reemplazar el objeto falso con nil (as is done here), pero try-catch es costoso en Objective -C y esto parece ser realmente mala idea.

+0

¿Está realizando una 'mergeChangesFromContextDidSaveNotification:' cuando el contexto secundario guarda y publica la notificación 'NSManagedObjectContextDidSaveNotification'? – dtrotzjr

+0

@dtrotzjr: Sí, lo soy. – Isaac

+0

¿Puede mostrar su código? Hay tantas cosas que puedes hacer mal. Sin ver tu código real, este es un juego de adivinanzas. Una posibilidad es que esté guardando usando performBlock: y que use el id del objeto en el contexto principal antes de que se ejecute performBlock :. Tu idea con try catch es mala. No lo intentes Resuelva el problema subyacente en lugar de corregir el síntoma con try catch. –

Respuesta

1

El problema podría ser en ID de objeto temporal. Object ID no es permanente hasta que se guarda en la tienda. Entonces, la pregunta es cuándo obtiene la ID del objeto de un objeto administrado en contexto secundario: antes de guardar el elemento primario o posterior.

Si hace esto antes de guardar el elemento primario (que a su vez, si el elemento primario está configurado con coordinador de tienda persistente y no con otro elemento primario, se guarda en la tienda), probablemente obtenga ID de objeto temporal. Y por algunas razones que Apple no nos revela, uno de los métodos que devuelven los objetos administrados de la ID de objeto funciona, pero el otro no.

Cuestiones relacionadas