NSRangeException después de la migración de Core Data

Después de agregar una nueva versión del modelo Core Data a mi aplicación, realicé una migración ligera, aparentemente con éxito. El archivo migrado se cargó bien, pero en el primer intento de acceder a un atributo a través de una relación particular, la aplicación se bloquea con unNSRangeException: '*** -[__NSArrayM objectAtIndex:]: index 4294967295 beyond bounds [0 .. 35]'. Esta relación funcionó bien antes de la migración. Sé por otras publicaciones aquí que 4294967295 es realmente-1, pero lo único que puedo identificar con 36 elementos en mi aplicación / datos es que hay 36 entidades en total en el modelo de datos (para referencia, la relación que se está buscando tiene 58 elementos en su tabla).

La pregunta:

Mi pregunta es: según el error que estoy obteniendo y la solución de problemas que he hecho a continuación, ¿hay algún tipo de cambio de esquema que pueda pasar la migración liviana, pero corrompa los datos en el camino, lo que lleva a la notable excepción? Voy a intentar dividir la migración en partes más pequeñas en varias versiones para aislar o evitar el problema, pero sería bueno poder centrarse en los cambios de esquema específicos que podrían estar en falta.

La falla:

El error se produce con el siguiente código en "myobject":

[[self object2] text];

La relación object2 es de uno a uno, no opcional en ambos sentidos y no se cambió la relación directa o inversa entre los modelos de datos. lostext atributo es probable que no sea relevante porque cuando se produce el error,awakeFromFetch No se alcanza en object2. Si asigno[self object2] a una variable anterior a la declaración anterior, la asignación es exitosa e informadata: <fault>.

La base de datos:

Al observar la base de datos en sqlite3, observo lo siguiente:

Los valores de índice para las relaciones directas e inversas parecen ser correctos en cada tabla.La tabla object2 tiene dos columnas para la relación inversa en lugar de la anterior a la migración (ZMYOBJECT como antes y el adicionalZ2_MYOBJECT, que está vacío para todas las filas). No se agregó ninguna otra relación para explicar esta columna.En elZ_PRIMARYKEY tabla, todas las entradas posteriores a la migración muestran-1 paraZ_MAX, mientras que antes de la migración, mostraban cero para las tablas vacías y el número máximo de filas para las tablas pobladas. Actualización manualZ_MAX a los valores adecuados no ayudó con la excepción. TodosZ_SUPER Los valores eran correctos.

Configuré un modelo de mapeo para ver si algo se veía mal con los mapeos automáticos, pero todo se veía bien.

Cambios generales del esquema:

En la versión de origen del modelo de datos, había catorce entidades, de las cuales solo cuatro se habían completado con datos (la aplicación aún está en desarrollo). Siete eran entidades de nivel superior y siete eran sub-entidades de tres de las entidades de nivel superior.

En la versión de destino del modelo de datos, se agregaron veintidós entidades, algunas de nivel superior y algunas subentidades, con docenas de relaciones, incluidas algunas agregadas a entidades existentes.

Algunos atributos y relaciones se eliminaron de las entidades existentes y otros se agregaron. No se cambiaron los tipos de datos ni la configuración de las relaciones, no se cambió el nombre de los atributos o las relaciones y no se requirieron asignaciones especiales.

Actualización (25/02/12): Cuando comencé a trabajar en un nuevo modelo intermedio, recordé que había cambiado la clase (representadaClaseNombre) para varias entidades desde NSManagedObject a una subclase NSManagedObject, pero no había generado los archivos de clase . No sospeché que eso causaría un problema y, de hecho, crear todos los archivos de clase no ayudó con la excepción. Sólo quería señalar que como otro cambio entre los modelos.

Conclusiones:

Esta es una suposición descabellada, pero si el recuento de 36 entidades no es una coincidencia, parece que cuando "myobject" intenta fallar en "object2" no tiene una referencia válida para la tabla y está intentando cargar la tabla número -1 , causando la excepción. El hecho de que una simple asignación de[self object2] Es exitoso, sin embargo, no concuerda con esa conclusión.

¿Algunas ideas?

Respuestas a la pregunta(3)

Su respuesta a la pregunta