Core Data : performBlock tout le temps ?
JegnuX
Membre
Salut,
J'aurais une question sur l'utilisation des méthodes performBlock et de performBlockAndWait de NSManagedObjectContext : que faut-il impérativement faire à l'intérieur de ces blocks et jamais à l'extérieur ?
Je précise que je travaille uniquement avec des context de type .PrivateQueueConcurrencyType ou .MainQueueConcurrencyType
Bon déjà je pense que tout ce qui vient de NSManagedObjectContext lui même doit-être fait dans ce block ( save(), executeRequest(), executeFetchRequest(), countForRequest(), insertObject(), deleteObject(), etc etc...)
Mon doute c'est plutôt pour tout le reste :
- get/set une value d'un managed object ?
- get/set une relationship d'un managed object ?
- faire un performFetch() sur un NSFetchedResultsController
- etc
Et aussi, est-ce vraiment important de passer par ces blocks si le context est de type .MainQueueConcurrencyType et qu'on est certains d'être sur la main thread (UI) ?
Et enfin, que ce passe-t'il si on imbrique plusieurs performBlock() et/ou performBlockAntWait() ?
Bon je suis conscient que ça fait finalement beaucoup de questions mais bon.
Merci d'avance !
Réponses
http://stackoverflow.com/questions/10445246/nested-performblock-on-nsmanagedobjectcontext
Je comprends pas vraiment la réponse en fait. Première fois que je rencontre cette notion de "reentrancy". ça veut dire que c'est bon y'a pas de soucis c'est ça ?
Cela veut dire que l'on peut appeler la fonction alors qu'elle est déjà en train de s'exécuter ; la fonction ne fera pas n'importe quoi.
Mais pour moi la ré-entrance ne suffit pas ici, car les appels ont lieu sur la même queue dans ton cas (de ce que j'en comprends en tout cas) ...
Je n'ai jamais tenté ce genre de manip. On peut supposer que la classe NSMAnagedObjectContext est codée de façon intelligente, et que ces méthodes adaptent leur comportement en fonction de la queue courante d'exécution.
Mais si ce n'est pas le cas, à mon avis, appeler performBlock à l'intérieur d'un performBlock sur la même queue n'est pas gênant en soi. Il faut tout de même que tu fasses attention car l'ordre d'exécution des opérations CoreData peut être perturbé.
Par exemple si tu exécutes un bloc A sur la queue privée qui fait la séquence suivante :
1. opérations A sur le contexte, en direct
2. opérations B dans un performBlock
3. opérations C en direct
4. opérations D dans un performBlock
L'ordre des opérations sera A, C, B, D, et pas A, B, C, D
En fait pour tester comment fonctionne performBlock, il suffit de tenter cette manip simplement en mettant des NSLogs dans les opérations A, B, C et D.
Quant à l'appel d'un performBlock ou performBlockAndWait à l'intérieur d'un performBlockAndWait ; s'il n'est pas écrit intelligemment, à mon avis c'est le blocage assuré (deadlock).