willTurnIntoFault ser llamado más de una vez, lo que resulta en un accidente

Question

En una subclase de NSManagedObject mi implementación sustituida del willTurnIntoFault está siendo llamado dos veces al deshacer algo de código que originalmente creó el objeto en cuestión. Esto resulta en un accidente al intentar anular el registro doble de MVA en una ruta de la clave.

Los documentos de Apple dicen que este es el lugar adecuado para un-registro de MVA.

Un poco de contexto - la operación de deshacer implica la eliminación de la vista correspondiente del modelo desde el mismo de la supervista. La vista conserva su modelo.

Así que mi pregunta es:? ¿Qué tipo de errores programador puede resultar en willTurnIntoFault se llama dos veces en una subclase de NSManagedObject

Nota: Anteriormente estaba preponderantes con dealloc en esta clase pero desde entonces han dado cuenta de esto no se recomienda para las subclases de NSManagedObject. ya me he mudado este código en -didTurnIntoFault. No estoy actualmente anulando cualquier otros métodos que la documentación de Apple decir que no debe anular.

Answer 1

Parece que el problema se debía a un método setter costumbre que estaba poniendo los valores MVA / desarmado desde dentro willTurnIntoFault.

Answer 2

Por el bien de la posteridad: Yo tenía el mismo problema. En mi caso tuve un objeto con una relación (a uno) a un objeto B . Cuando que se borraron B 's relación inversa a se estableció en null. Esto causó B 's método observeValueOfKeyPath:ofObject:change:context que se invoca (donde keypath fue B ' s relación a A ). Desafortunadamente este método comprobado una propiedad de , haciendo que el fallamiento de que ser cancelado (nota que en esta situación awakeFromFetch no se consiga llamar - supongo que debido a que el objeto nunca en realidad lo hizo llegar al estado de error). De ahí que podría podría recibir una segunda llamada a willTurnIntoFault más tarde y el objeto trataría de anular el registro de MVA de nuevo, lo que resulta en un accidente -. Al igual que en el OP

Para mí la solución era cambiar la norma de supresión de la A a la cascada, de modo que el objeto B se borraron cuando se borraron el objeto A y para anular el registro de MVA en prepareForDeletion. Esto es importante debido a que la eliminación de se sigue causar B 's relación inversa que se fijará a cero antes de B se elimina realmente.

Tenga en cuenta que prepareForDeletion se llama antes de pero no en lugar de willTurnIntoFault. Por lo tanto, si anular el registro de MVA tanto, es necesario mantener un cierto estado para asegurarse de que no lo ha registrado.