10

Ho creato due contesto come questo:Strano padre/figlio NSManagedObjectContext fenomeno

// create writer MOC 
_privateWriterContext = [[NSManagedObjectContext alloc] initWithConcurrencyType:NSPrivateQueueConcurrencyType]; 
[_privateWriterContext setPersistentStoreCoordinator:_persistentStoreCoordinator]; 

// create main thread MOC 
_managedObjectContext = [[NSManagedObjectContext alloc] initWithConcurrencyType:NSMainQueueConcurrencyType]; 
_managedObjectContext.parentContext = _privateWriterContext; 

Ho un NSFetchResultedController avviata con _managedObjectContext.

So che è strano, ma sto aggiungendo un record al genitore a _privateWriterContext, sono saving esso.

Ciò che sorprende è che il contesto figlio e così FRC venga avvisato di questo evento. Perché? Non ho il figlio con reset o altro. Ho pensato che fossero entità indipendenti fino a quando il contesto figlio non verrà salvato.


Nell'articolo @pteofil ho trovato questa linea:

Quando viene apportata una modifica in un contesto, ma non salvato, è visibile a tutti i suoi discendenti, ma non ai suoi antenati .

.. viene inviato all'archivio permanente (tramite il coordinatore del negozio permanente) e diventa visibile a tutti i contesti connessi al negozio.

+2

In base a questo articolo http://benedictcohen.co.uk/blog/archives/308, questo è un comportamento normale. – pteofil

+1

E un altro ottimo articolo sulle prestazioni di diverse impostazioni del contesto gestito: http://floriankugler.com/2013/04/29/concurrent-core-data-stack-performance-shootout/ – pteofil

+0

Vedo, pensi che sia in qualche modo possibile impedire che le modifiche si propagino nel contesto secondario? Ho pensato che le modifiche non verranno propagate fino a quando non osserverò "NSManagedObjectContextDidSaveNotification" e unirò le modifiche dalla notifica se sto usando due context che si uniscono alla stessa configurazione PSC –

risposta

0

Questo non dovrebbe accadere. L'aggiunta di un NSManagedObject ('record') a parentContext, non renderà automaticamente il bambino consapevole di questo oggetto. Solo quando si esegue il childContext eseguire un recupero, quindi verrà recuperato dal parentContext. di capire cosa sta succedendo nel vostro caso, ecco alcuni suggerimenti:.

  • capire quando una recuperare viene eseguito sul childContext (questo viene fatto dal fetchedRestultsController quando lo si imposta Verificare che recuperano succede prima o dopo aver aggiunto il managedObject al parentContext).
  • imposta i punti di interruzione in tutti e quattro i callback del delegatoResultsController per scoprire per quale oggetto chiama i metodi (e vedere se è l'oggetto che hai appena aggiunto al parentContext).
  • assicuratevi assolutamente di sapere in quale contesto state inviando messaggi.

ho un usato un approccio simile, ma diverso: la childContext è il contesto viene utilizzato per analizzare in nuovi dati (su una coda privata), e quando questo è fatto l'analisi, le chiamate chid salvare :. Ciò salverà le modifiche fino al genitore, che è nel mio caso il mainQueueContext. Questa chiamata al salvataggio: farà sì che mainQueueContext riceva tutti gli oggetti appena analizzati, e qualsiasi fetchedResultsController che usa quel mainQueueContext chiamerà quindi i suoi metodi delegati per gli oggetti nuovo/modificato/aggiornato/cancella. Si potrebbe provare anche a invertire la relazione figlio/genitore e vedere se funziona come descritto nei documenti, solo per scoprire cosa sta succedendo.

0

Si consiglia vivamente di evitare impostazioni del contesto padre-figlio. Il nostro libro va in dettaglio perché spesso portano a strani comportamenti: https://www.objc.io/books/core-data/

Breve storia: non sono così indipendenti come si potrebbe pensare.

Utilizzare più contesto che condividono un singolo coordinatore di archivio persistente se è necessario più di un singolo contesto.

Problemi correlati