ios - Does Core Data actually save any changes to disk before updating NSFetchedResultsControllers? -
this specific question , i've been bitten now, save others time , agony, here's problem in-depth , solution.
when save main context, instance, , triggers nsfetchedresultscontroller delegate callbacks, can depend upon fact save has completed, , safely perform new fetch requests within callbacks assuming saved data included?
the answer no.
if have active nsfetchedresultscontroller's (nsfrc) in app have delegate set , monitoring changes relevant objects, here's small undocumented caveat core data developers should aware of. if perform save on main context, , have nsfrc's working on main context, calling save:
on main context update nsfrc first , call willchangecontent:..
, didchangecontent:..
, etc. callbacks on nsfrc delegate before saving moc contents disk.
the reason why problematic if try execute new fetch request using resulttype of nsdictionaryresulttype
inside nsfrc callbacks, fetch request won't include current changes. current changes, mean changes nsfrc callbacks called in first place.
the reason why won't see changes because setting resulttype nsdictionaryresulttype
turns off includespendingchanges
property. fetch request gets changes directly disk , doesn't merge local changes context.
i can understand reasons why arbitrary fetch requests using dictionary result type don't merge unsaved results context since dictionaries have arbitrary structure, while moc modeling objects , relationships in graph, however, part interesting , surprising me nsfrc delegate got update callbacks before save done.
here's ascii art:
1. save main moc --> | 2. nsfrc callbacks --> | 3. actual save happens here | | | | | | | ▼ | | nsdictionaryresulttype | | fetch requests won't | | see changes | | current save, | | regular fetch requests | | see changes |
ps: core data object-graph management framework runs on limited performance devices. gotta optimize.
Comments
Post a Comment