2012-05-18 21 views
10

Ok, więc jest to błąd Dostaję„NSInternalInconsistencyException”, powód: „Foo” nie jest podklasą NSManagedObject

*** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: '"Place" is not a subclass of NSManagedObject.' 

Przypuszczam, że to, co to znaczy, że „miejsce” nie zostało dodane jako jednostka do podstawowego modelu danych? Ale ma to jak pokazano na poniższym obrazku.

Zgaduję, że moje założenie jest nieprawidłowe, więc każda pomoc lub pomysł byłby niezły.

jestem całkiem pewny, że jest to linia, która jest przyczyną go:

NSManagedObject* place = [NSEntityDescription 
           insertNewObjectForEntityForName:@"Place" 
           inManagedObjectContext:context]; 
+0

Czy "kontekst" jest prawidłowy po uruchomieniu tej linii? (Non-nil, ma połączenie z stałym koordynatorem sklepu ....) –

Odpowiedz

23

Jeśli nie używasz niestandardowych klas (nie miejsce [hm].), Jak to brzmi jak nie jesteś, sprawdź kartę Entity, i upewnij się, że nazwa Klasa jest puste (= NSManagedObject) - nie Place.

+0

Champion! Nie pamiętam, żeby to dotknąć. Co spowodowałoby to zmianę? – user1135469

+0

Domyślam się, że podklasa dla encji jest w rzeczywistości domyślna. – paulmelnikow

+0

Dzięki @noa :) zaoszczędziłeś mi czasu .. – Rupesh

-1

Innym sposobem rozwiązania tego problemu jest użycie podklasy NSManagedObject (zalecane).

Place *place = [NSEntityDescription 
          insertNewObjectForEntityForName:@"Place" 
          inManagedObjectContext:context]; 
+0

Dokonywanie Umieść podklasę NSManagedObject wymagałoby innego podejścia niż to. Zmiana typu zmiennej nie wpłynie na klasę obiektu. – paulmelnikow

+0

Nie, nie byłoby. Jak już wspomniano, jest to ustawienie domyślne, a zatem zalecane. Jest na przykład o wiele bezpieczniejsze używanie jawnych nazw atrybutów niż uzyskiwanie dostępu do atrybutów za pomocą kodowania klucz-wartość. – Mundi

12

Miałem ten sam problem z klasami o nazwie Wiadomość i połączenie. Błąd pojawił się po dodaniu narzędzia do wysyłania wiadomości e-mail przy użyciu biblioteki MessageUI. Wierzę, że konflikt występuje, ponieważ biblioteka będzie miała klasy o nazwie Message i Connection, dlatego nie są one uważane za podklasy NSManagedObject. Zmiana ich nazw przez prefiksowanie (w moim przypadku przez X) sprawia, że ​​jednostki są unikalne. Zamierzam w przyszłości prefiksować wszystkie moje jednostki, aby szanse wystąpienia konfliktu były mniejsze.

+1

Doh, dobre znalezisko. Miał podmiot o nazwie Wiadomość, który rzucał to fatalne. –

+0

dosłownie miał dokładnie ten sam problem, z klasy o nazwie „Połączenie”. Przedrostek nazwy działał świetnie, dzięki. –

0

Pierwszą rzeczą, którą należy zrobić, gdy napotkasz tego rodzaju błędów jest sprawdzenie nazwę klasy swojej jednostki:

  • Otwórz XCDataModel
  • wybrać swoje podmiot
  • Otwórz prawe okienko Użytkowe
  • Kliknij przycisk "pokaż przycisk inspektora modelu danych"
  • Sprawdź nazwę klasy, aby była zsynchronizowana z wygenerowanym modelem

Mam nadzieję, że to pomoże!

Powiązane problemy