Hay un comportamiento muy molesta de ir a buscar solicitudes, según lo documentado por Apple:
Si un objeto en un contexto ha sido modificado, un predicado se evalúa contra su estado modificado, no contra el estado actual en la tienda persistente. Por lo tanto, si un objeto en un contexto se ha modificado de manera que cumpla con los criterios de solicitud de recuperación, la solicitud lo recupera incluso si los cambios no se han guardado en la tienda y los valores en la tienda son tales que no cumple los criterios. Por el contrario, si un objeto en un contexto se ha modificado de manera que no coincida con la solicitud de búsqueda, la solicitud de recuperación no lo recuperará, incluso si la versión en la tienda coincide.
Es posible que usted está despejando la fecha en otros lugares y la solicitud de búsqueda está incluyendo los resultados en que la fecha es nil
en la memoria, pero aún situado en disco (en el almacén persistente), y así, cuando los defectos del objeto se carga el objeto con la fecha establecida.
Mi único consejo sería coordinar el acceso al contexto del objeto gestionado (por ejemplo, en un NSOperationQueue
) para que cualquier actualización pueda guardarse en el almacenamiento persistente antes de ejecutar la solicitud de búsqueda.
¿Sabe por qué el formato debe ser @ "endDate = nil" y no @ "endDate == nil"? Hubiera pensado con seguridad que debería ser el signo doble igual, pero == no produce el efecto deseado en este caso. Impar porque otras comparaciones de predicados sí funcionan con ==. – kris
@kris No estoy seguro. http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/Predicates/Articles/pSyntax.html#//apple_ref/doc/uid/TP40001795-SW1 parece sugerir que '=' y '= = 'son equivalentes, pero los ejemplos en http://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/Predicates/Articles/pUsing.html#//apple_ref/doc/uid/TP40001794-SW4 usan' = ' –
gracias.Estoy viendo que = y == no se están comportando igual en esta circunstancia así que se dirige a todos – kris