"CoreData nie obsługuje trwałych relacji między sklepami" pomimo zgodności z identyfikatorami x-coredata

Question

Zapisując kontekst obiektu zarządzanego Rdzeń danych w systemie iOS 6.0.1 do magazynu SQLite, natknę się na dziwne "CoreData nie obsługuje ciągłego krzyżowania się - wyjątek dotyczący relacji z magazynem. Dotyczy to relacji jeden-do-jednego między cytatami i zasobami AbstractSources w modelu. Przy starcie to dotyczy Cytat i książki

mam zbadane podobne raporty i pokryte zgłoszone przyczyn (gdzie Book dziedziczy AbstractSource Wszystko działa dobrze w edytorze modelu..):

1. ja przypisaniem zarówno cytat, jak i książka do tego samego trwałego magazynu przy użyciu assignObject: toPersistentStore :, więc żadne z nich pozostaje nieprzypisane.
2. Opis błędu pokazuje, że wszystkie "absolutne" x-CoreData identyfikatory zaczynają z tym samym prefiksem (np "x-CoreData: // 82B3BEB3-60F2-4912-AC80-11AAD29CFF99 /", więc nie wydaje się naprawdę być jeden sklep tylko w użytku

moje pytania są następujące:..

1. Czy coś jeszcze muszę sprawdzić (może SG w stosunku do AbstractSource, których nie należy dotykać/kontroli w moje źródło? Jestem tworząc zarówno cytat, jak i książkę h wywołanie initWithEntity: insertIntoManagedObjectContext each.)
2. Zauważyłem, że opis błędu zawiera również kilka "względnych" identyfikatorów x-coredata (o postaci "x-coredata: /// ..."). Czy to możliwe, że bezwzględna forma jest zawsze uważana za "krzyżową bazę danych", nawet jeśli przedrostki "bezwzględne" (patrz przykład powyżej) są takie same? A jeśli tak, to w jaki sposób mogę wpłynąć na wybór pomiędzy "absolutnymi" i "względnymi" identyfikatorami x-coredata?

Thx (dużo) za uwagę!

Answer 1

Więc to jest to, co mieliśmy (przypuszczalnie) spowodowało problemy: koordynator

1. zarządzanym przeze mnie kontekst obiektu musi zarządzać dwa uporczywe sklepów. Teraz ten, do którego przypisałem Quote and Book i czy jestem , czy zapisano je, jest resetowany przy starcie. W tym kodzie był błąd , który uniemożliwił korzystanie z tego sklepu. Ponieważ dostępny był drugi numer , przejął on w milczeniu, w tym przypadku prowadząc do niechcianych wyników. Lekcja: Teraz stwierdzam, że istnieją/pozostają dwa sklepy po ustawieniu podstawowego stosu danych.
2. Podczas wcześniejszego rozwoju mojego modelu Core Data zmieniłem nazwę pewnego jego obiektów w edytorze modelu. Przez pomyłkę zmieniłem tylko nazwy , ale nie właściwości klasy encji. Tak więc, podczas gdy wszystko działało dobrze w edytorze modelu, do czasu wykonania użyto w klasach wykonawczych nieoczekiwanych klas , a zatem nieoczekiwanych klas, w których przypisano również do nieoczekiwanych/błędnych sklepów. Lekcja: Teraz upewniam się, że nazwy encji i ich właściwości klas pozostają w doskonałej synchronizacji (inne okoliczności pozwalają na to).

Problem został rozwiązany, a ja również refactored mojego kodu/model do użycia (nie pokrywających) configurations zamiast wyraźnych zadań, które powinny również pomóc w przyszłości.

Jeszcze raz na twoją uwagę