2010-11-18 12 views
5

Mam opartą na dokumencie aplikację Core Data, która działa tak jak jest. Chciałbym dodać obsługę globalnego magazynu trwałego do przechowywania biblioteki przedmiotów.Podstawowa aplikacja oparta na dokumencie danych z globalnym trwałym sklepem

Przeczytałem większość odpowiednich dokumentów i rozumiem, że powinienem używać konfiguracji w zarządzanych modelach obiektów. Zdefiniowałem dwie konfiguracje: "DocumentConfiguration" i "LibraryConfiguration". Obiekty w konfiguracji dokumentu znajdują się tylko w konfiguracji dokumentu, a elementy w konfiguracji biblioteki znajdują się tylko w konfiguracji biblioteki - tzn. Nie pokrywają się.

Dokumenty następnie mówią: "Używasz tego modelu podczas tworzenia koordynatora". Ale tak naprawdę nie utworzyłem własnego koordynatora sklepu trwałego, ponieważ używam domyślnego koordynatora NSPersistentDocument.

Kilka pytań na temat, jak najlepiej postępować i pomóc wyjaśnić wszelkie nieporozumienia może mam:

A. Chciałbym uzyskać NSPersistentStoreCoordinator w NSPersistentDocument a następnie dodać nowy sklep trwałe do niej wzdłuż linii:

NSPersistentStoreCoordinator * coordinator = [[myDocument managedObjectContext] persistentStoreCoordinator]; 
[coordinator addPersistentStoreWithType:NSXMLStoreType 
    configuration:@"LibraryConfiguration" 
    URL:url 
    options:nil 
    error:&error]; 

myślę, że może to być problem, bo nie dostarczyły inną definicję konfiguracji („DocumentConfiguration”) w przetrwałym koordynatora przechowywać NSPersistentDocument jako używam domyślnego dostarczone przez NSPersistentDocument. Zgaduję, że prawdopodobnie przydałoby się zero, gdy nadszedł czas, aby zapisać dokument. A jeśli tak, czy to byłby problem? Tj. W jaki sposób koordynator będzie wiedział, który magazyn trwałej, aby zapisać jednostkę z daną definicją konfiguracji, jeśli te same konfiguracje nie są zdefiniowane dla wszystkich trwałych sklepów (w tym przypadku dwóch)? Czy jestem w stanie ustawić konfigurację (na "DocumentConfiguration") magazynu trwałego NSPersistentDocument przed jej utworzeniem/zapisaniem? Od docs NSPersistentDocument:

Saving a new document adds a store of the default type with the chosen URL and invokes save: on the context. For an existing document, a save just invokes save: on the context.

B. Byłoby lepiej, aby utworzyć własne instancje NSPersistentStoreCoordinator i NSManagedObjectContext, dodając dwa sklepy z trwałych określonych konfiguracjach, a następnie dokonać NSPersistentDocument używać tych wystąpień NSPersistentStoreCoordinator i NSManagedObjectContext i wolne stare? Jeśli tak, to w jaki sposób określić adres URL dla NSPersistentDocument dla metody addPersistentStoreWithType: ...? Wygląda na to, że ten adres URL jest znany tylko po zapisaniu dokumentu bez tytułu. (Testowanie tego powoduje, że nie ma tymczasowego magazynu trwałego (za pośrednictwem metody persistentStores na trwałym koordynatorze sklepu), dopóki dokument nie zostanie zapisany po raz pierwszy).

C. Czy lepiej zostawić NSPersistentDocument sam i utworzyć własną instancję NSPersistentStoreCoordinator, której używam wyłącznie w przypadku trwałego magazynu biblioteki i zarządzanego modelu obiektu biblioteki? Dokumenty mówią, że wiele wystąpień NSPersistentStoreCoordinator powinno być używanych w wielowątkowych aplikacjach Core Data, ale nie potrzebuję wielowątkowej obsługi danych rdzenia. Czy jest pożądane posiadanie dwóch instancji NSPersistentStoreCoordinator - jednego dla biblioteki i drugiego dla dokumentów (intuicja mówi, że nie jest to konieczne i prawdopodobnie nie jest to właściwe podejście)?

Wszelkie sugestie?

Odpowiedz

1

Rozwiązanie, którego użyłem, działa dobrze, opiera się na C) powyżej. Pozostawiam sam NSPersistentDocument i jego stały koordynator sklepu, a zamiast tego tworzę własną instancję NSPersistentStoreCoordinator, której używam wyłącznie w przypadku trwałego magazynu biblioteki (sklepu globalnego).

Mogę ustawić konfigurację sklepu na niestandardową wartość, na wypadek gdyby chciałbym mieć wiele sklepów powiązanych z tym trwałym koordynatorem sklepu później (np. "LibraryConfiguration"). Ponieważ magazyn biblioteki jest zarządzany przez stałego koordynatora sklepu innego niż stały koordynator sklepu NSPersistentDocument, nie muszę przejmować się konfigurowaniem trwałych magazynów NSPersistentDocument.

0

Należy utworzyć osobny magazyn trwały dla każdej konfiguracji. Po to jest konfiguracja, aby umożliwić przechowywanie różnych jednostek w tym samym modelu danych w oddzielnych trwałych plikach.

Typowym błędem jest zapomnienie, że stały koordynator sklepu może mieć dowolną liczbę trwałych zapasów.Wszystko, co musisz zrobić, to zduplikować płytę główną firmy Apple, aby utworzyć dwa trwałe magazyny o różnych nazwach i/lub lokalizacjach, a każda z inną nazwą konfiguracji. Następnie dodaj oba do stałego koordynatora sklepu.

I gotowe. Instancje encji dla każdej konfiguracji przejdą do właściwego sklepu.

+0

Jednak dokumentacja NSManagedObjectContext ma tylko metody pobierania/ustawiania stałego koordynatora sklepu, a nie dodawania go. Oznacza to, że z mojego zrozumienia nie można mieć więcej niż jednego stałego koordynatora sklepu powiązanego z kontekstem obiektu zarządzanego. (Trwały koordynator sklepu powiązany z kontekstem obiektu zarządzanego może zarządzać wieloma magazynami trwałymi, ale jest inaczej). – Dalmazio

+0

Przepraszam, napisałem błąd. W rzeczywistości dodajesz wiele sklepów do stałego koordynatora sklepu za pomocą 'addPersistentStoreWithType: configuration: URL: options: error:' – TechZen

+0

Ok, ale nadal istnieje problem związany z tą sytuacją (integracja globalnego magazynu trwałego i magazynu opartego na dokumencie application) wywoływania addPersistentStoreWithType: ... na trwałym koordynatorze sklepu NSPersistentDocument, jak opisano w punkcie A) powyżej. – Dalmazio

Powiązane problemy