I have been using Core Data for a while now, several years at least. Over time, I have learned how it works internally and learned to side-step possible issues and shortcomings. The following is a unordered list of tidbits.
Don’t ever check the Core Data flag when creating the project. Add your model afterwards and…
Use RTCoreDataStack. I’m eating my own dog food and am using it (or its lesser variants) for years now, rarely an issue, if the following rules are obeyed.
This particular stack is amazing for background imports that also update/change stuff that may influence main thread/UI.
NSFRC always maintains cache, even if you don’t set the cacheName. Setting
cacheName means that it will persist its cache between app starts. Not setting it means that cache will be memory-only for the duration of current app session.
You can change both
predicate for the
NSFetchRequest, if you kill the cache first. If you haven’t set cacheName, there’s nothing to kill.
So, don’t set the cacheName for the NSFRC. Ever. Win-win.
Relationships changes and NSFRC
NSFRC will not react when you change relationships to the object it’s based on. This will not affect you if your views are very simple (use only that one particular object) or your object graph is totally denormalized. Mine are usually neither.
Say you have canonical example of Person object that you are showing and it has Department relationship. In each person’s cell you want show its department’s name. If that name changes, NSFRC will not pick that up on its own - it only looks into the attributes for the Person.
Thus you need to trick it; this is how to kick NSFRC’s reaction:
1 2 3 4 5 6 7 8 9 10 11
It’s a hack, but it works in practice.
Wounds from practice
If you have a
transformable property which is actually an NSArray, this will work:
But, if you supply a value of
n which does not exists in the
arrayAsTransformableProperty in any of the objects, then you get a very ugly
EXC_BAD_ACCESS (code=1,address=0x0) crash:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
So yeah – don’t save NSArrays into the Core Data. Convert it to CSV string and save that.
Don’t use direct relationships in sortDescriptors. It can crash during
[NSMO compare:] when your
didSaveNotification is handled and causes NSFRC delegate call to do
I have done this and in some obscure confluence of edge cases got this crash:
[NSMOSubclass compare:] unrecognized selector sent to instance …
For NSFRC sortDescriptors, use number/string attributes, never relationships.
When defining your model, do not insert default values, unless you really, really need them. Instead, make the attribute optional, if possible.
The reason is that if you have only some of the values, it becomes much harder to use some advanced data extraction features, like calculating averages (where missing data should be ignored).