Pułapki korzystania z dwóch stałych koordynatorów sklepu w celu wydajnej aktualizacji tła

Bazując na twoim pytaniu, komentarzach i moim własnym doświadczeniu, wydaje się, że większym problemem, który próbujesz rozwiązać, jest: 1. Używanie kontrolera nsfetchedresultscontroller na głównym wątku z ograniczeniem wątku 2. Importowanie dużego zestawu danych, który wstawia, aktualizuje lub usuwa zarządzane obiekty w kontekście. 3. Import powoduje, że duże powiadomienia scalania są przetwarzane przez główny wątek w celu aktualizacji interfejsu użytkownika. 4. Duże połączenie ma kilka możliwych efektów: - Interfejs staje się powolny lub zbyt zajęty, aby mógł być użyteczny. Może to być spowodowane używaniem beginUpdates/endUpdates aby zaktualizować widok tableview w NSFetchedResultsControllerDelegate, i masz wiele animacji quiing up z powodu dużego scalenia. - Użytkownicy mogą napotkać "nie udało się spełnić błędu", gdy próbują uzyskać dostęp do uszkodzonego obiektu, który został usunięty ze sklepu. Kontekst zarządzanego obiektu myśli, że istnieje, ale kiedy trafia do sklepu w celu spełnienia błędu, Błąd został już usunięty. Jeśli jesteś używając reloadData do aktualizacji widoku tabeli w kontrolerze NSFetchedResultsControllerDelegate, jest bardziej prawdopodobne, że to się stanie niż podczas używania beginUpdates/endUpdates.

Podejście, które próbujesz wykorzystać do rozwiązania powyższych problemów jest: - Utwórz dwa NSPersistentStoreCoordinators, każdy dołączony do tego samego NSPersistentStore lub co najmniej ten sam adres URL pliku nspersistentstore SQLite. - Twój import następuje na NSManagedObjectContext 1, dołączonym do NSPersistentStoreCoordinator 1, oraz wykonanie na innym wątku (wątkach). Twój kontroler NSFetchedResultsController używa NSManagedObjectContext 2, dołączonego do NSPersistentStoreCoordinator 2, działającego w głównym wątku. - Przenosisz zmiany z NSManagedObjectContext 1 na 2

Napotkasz kilka problemów z tym podejściem. - An NSPersistentStoreCoordinator ' S zadaniem jest pośredniczenie pomiędzy dołączonymi do niego NSManagedObjectContexts a dołączonymi do niego magazynami. W scenariusz multiple-Coordinator-context, który opisujesz, zmiany w bazowym sklepie przez NSManagedObjectContext 1, które powodują zmianę w pliku SQLite, nie będą widoczne przez NSPersistentStoreCoordinator 2 i jego kontekst. 2 nie wie, że 1 zmienił plik, a będziesz miał "nie mógł spełnić błędu" i inne ekscytujące wyjątki. - Nadal będziesz musiał w pewnym momencie umieścić zmienione NSManagedObjects z importu do nsmanagedobjectcontext 2. Jeśli te zmiany są duże, możesz nadal będzie miał problemy z interfejsem użytkownika, a interfejs będzie zsynchronizowany ze sklepem, co może prowadzić do "nie udało się spełnić błędu". - W ogóle, ponieważ NSManagedObjectContext 2 nie używa tego samego NSPersistentStoreCoordinator jak NSManagedObjectContext 1, będziesz miał problemy z rzeczy są synchronizowane. Nie tak te rzeczy mają być używane razem. Jeśli importujesz i zapisujesz w NSManagedObjectContext 1, NSManagedObjectContext 2 jest natychmiast w stanie niezgodnym z sklep.

Oto niektóre z rzeczy, które mogą pójść nie tak z tym podejściem. Większość z tych problemów będzie widoczna podczas odpalania usterki, ponieważ dostęp do sklepu. Więcej na temat działania tego procesu można przeczytać w Core Data Programming Guide, natomiast Incremental Store Programming Guide opisuje proces bardziej szczegółowo. Sklep SQLite postępuje zgodnie z tym samym procesem, co przyrostowa implementacja sklepu.

Znowu przypadek użycia opisujesz-pozyskiwanie mnóstwa nowych danych, wykonywanie find-Or-Create Na danych w celu tworzenia lub aktualizacji zarządzanych obiektów oraz usuwanie "starych" obiektów, które mogą w rzeczywistości stanowić większość sklepu-to coś, z czym mam do czynienia każdego dnia od kilku lat, widząc wszystkie te same problemy, które Ty masz. Istnieją rozwiązania-nawet w przypadku importu, który zmienia 60 000 złożonych obiektów na raz, a nawet przy użyciu zamknięcia wątku! - ale to nie wchodzi w zakres twojego pytania. (Podpowiedź: Konteksty rodzic-dziecko nie wymagają scalania powiadomień).

Dwóch stałych koordynatorów sklepów (PSC) jest z pewnością drogą do dużych zbiorów danych. Blokowanie plików jest szybsze niż blokowanie podstawowych danych.

Nie ma powodu, abyś nie mógł użyć psc w tle do utworzenia wątku ograniczonego NSManagedObjectContexts, w którym każdy jest tworzony dla każdej operacji wykonywanej w tle. Jednak zamiast pozwolić core data zarządzać kolejką, musisz teraz utworzyć NSOperationQueues i / lub wątki do zarządzania operacjami w oparciu o to, co robisz to w tle. Nsmanagedobjectcontext są bezpłatne i nie są drogie. Gdy to zrobisz, możesz zawiesić swój NSManagedObjectContext i używać go tylko podczas tej jednej operacji i / lub czasu życia wątków i zbudować tyle zmian, ile chcesz i poczekać do końca, aby zatwierdzić je i scalić je do głównego wątku, jak kiedykolwiek zdecydujesz. Nawet jeśli masz jakieś główne wątki, możesz nadal w kluczowych punktach w czasie życia operacji refetch / scalić z powrotem do kontekstu wątków.

Ważne jest również, aby wiedzieć, że jeśli pracujesz na dużych zestawach danych, nie martw się o łączenie kontekstów, tak długo, jak nie dotykasz czegoś innego. Na przykład, jeśli masz klasę A i klasę B i masz dwie oddzielne operacje / wątki do pracy nad nimi i nie mają one bezpośredniego związku, nie musisz łączyć kontekstów, jeśli jeden się zmieni, możesz kontynuować toczenie ze zmianami. Jedyną istotną potrzebą łączenia kontekstów tła w ten sposób jest to, że istnieją bezpośrednie związki. Lepiej byłoby temu zapobiec poprzez jakąś serializację, czy to NSOperationQueue, czy co innego. Więc nie krępuj się pracować na różnych obiektach w tle, po prostu uważaj na ich relacje.

Pracowałem nad dużymi projektami core data i ten wzór działał bardzo dobrze dla mnie.

Rzeczywiście, jest to najlepszy scenariusz baz danych, z którym możesz pracować. Prawie brak głównego interfejsu użytkownika i łatwe zarządzanie danymi w tle. Jeśli chcesz podać główny kontekst (i być może aktualnie działający NSFetchedResultsController), słuchasz powiadomień o zapisie tła w następujący sposób:

    [[NSNotificationCenter defaultCenter] 
      addObserver:self selector:@selector(reloadFetchedResults:)
      name:NSManagedObjectContextDidSaveNotification
      object:backgroundObjectContext];

Następnie, można scalić zmiany, ale czekając na kontekst głównego wątku, aby je złapać przed zapisaniem . Po otrzymaniu powiadomienia mergeChangesFromContextDidSaveNotification zmiany nie są jeszcze zapisywane. Stąd {[4] } jest obowiązkowe, więc główny kontekst pobiera zmiany, a następnie NSFetchedResultsController poprawnie aktualizuje swoje wartości.

-(void)reloadFetchedResults:(NSNotification*)notification
{
    NSManagedObjectContext*moc=[notification object];
    if ([moc isEqual:backgroundObjectContext]) 
    {
        // Delete caches of fethcedResults if you have a deletion
        if ([[theNotification.userInfo objectForKey:NSDeletedObjectsKey] count]) {
            [NSFetchedResultsController deleteCacheWithName:nil];
         }
        // Block the background execution of the save, and merge changes before
        [managedObjectContext performBlockandWait:^{
            [managedObjectContext 
            mergeChangesFromContextDidSaveNotification:notification];
        }];
    }
}