I'm using Core Data in my project. I have an entity, EntityMO that has a 1-to-many optional relationship with RelationMO.
When I make the call myEntity.myRelation in my code (to see if the RelationMO object exists), is that going to cause a table lookup every time? Or is there some black magic happening with Core Data?
Or is there some black magic happening with Core Data?
Simply getting the object will usually not require accessing the data store, but the object you get in that case will be a fault, not the actual stored object. When you use the object, the fault will fire, causing the object to be realized. There are a few operations (e.g. -isEqual:) that will not cause a fault to fire -- see the docs for more information.
Faults are realized behind the scenes and so may seem like black magic, but it's better to think of them as delayed gratification.
Related
Apple describes faults as partially materialised futures which is very similar to the term partially materialised views used in several databases. Word partial means for me that some field of this object are initialised (realised) and some not. But Apple describes faults as:
A managed object fault is an instance of the appropriate class, but its persistent variables are not yet initialized.
Are there any way to partially realise a fault? E.g. I have object with 10 field and I want a partial object with only two fields realised while the whole object is still a fault (hence all other fields are still nil). I'm not talking about propertiesToFetch of NSFetchRequest here but about so called partial faults.
Because currently when fault is fired all properties are realised. Here is a quote from the docs:
If you access a property on the Department object — its name, for example — the fault fires and Core Data executes a fetch for you to retrieve all of the object's attributes
How can I customise fault realisation?
I don't believe that there is anyway to do this. When core data loads a managedObject it loads everything. You can see in NSMangedObject's interface that it has a single property of isFault which is either true of false.
If you have a property that is very large (a blob of data for example) and don't want to load it unless it is needed, then I would suggest storing it as a separate entity with a relationship. This way it will only be loaded (faulted) when you request the property.
I have an issue where if I make changes to a core data object, save then refreshing the object, causes my NSFetchedResultsController to show a duplicate object. I think I understand what's going on, but I'm looking for someone to confirm, and also to hopefully give some more detail as to why.
To explain in more dtail I have two entities, Fixture and Position. A Fixture has many Positions, and a Position belongs to only one Fixture. To reproduce the issue I do the following:
Fetch all Positions.
Modify some value (any one) on that objects Fixture. I.E foo.fixture.name = "foobar"
Save the context
Refresh objects by calling context.refreshAllObjects, or context.refreshObject(foo, mergeChanges: false/true).
I have a tableview using a fetched results controller which displays Fixures. After doing the above the tableview will display duplicates for each item (it doesn't matter if I use the delegate methods of the FRC to do the update or I just reload the tableview).
It appears what's happening is that the refresh invalidates the objects that the FRC knows about, while at the same time gets knowledge of another set of objects. If, as step #5, I call frc.performFetch() then the problem goes away.
Other things to note:
No matter how many times I run the code I only get two of each object (I'm using a random button to trigger it for testing).
init(entityName, context) is called on my Fixture subclass as soon as I access the Fixture property of my object during the next code run (i.e after refresh was called).
In my sample everything is taking place on the same context (though it happens with child contexts as well)
To give some more context as to how I got myself in this situation in the first place users can click on a fixture in the list and then ultimately narrow down on a single position a few screens later where they can perform actions that modify the fixture. There are other active areas of the application at this point that are listening to the NSManagedObjectContextDidSaveNotification and I want them to update their objects so they can display the correct data, which is why I was calling refresh.
I've dug around in the docs and I can't see anything that specifically explains my theory that updating the context causes NSFetchedResultsController to have invalid objects. Can anyone shed some light on this behavior?
First, you really should not be overriding -init... on a NSManagedObject. That is one of the methods that you are strongly discouraged from overriding and can very easily be the source of your issues.
Second, your entire UI should be using a single instance of the NSManagedObjectContext that is associated to the main queue and therefore there should only be ONE instance of any particular entity in your UI. If you have multiple contexts you are just making things more complicated for yourself. If you are using a single context keep in mind that no matter how many times you fetch an object against that context you will get the exact same pointer back.
The NSFetchedResultsController will never create objects, it only fetches and provides them for display. Therefore the NSFetchedResultsController is only reporting the fact that you have created this duplication somewhere else in your code.
Now some questions, do these duplicates get pushed down to disk?
Can you see them in the store file on disk?
When you re-launch your application are the duplicates still there?
When you put a print in your custom -init methods on the NSManagedObject; do they fire more than once?
I am new with Core Data and have a problem which sounds trivial to solve (at least thinking in SQL) but I can't get my head around that with Core Data.
What I'm trying to do is the following: I have a fetched ManagedObject, do some changes and save it again. This ManagedObject has an attribute id. I want to write the changes I made to this ManagedObject to all the ManagedObjects with the same id.
I was thinking to overwrite willSave: and fetching the other ManagedObjects with the same id there but this won't work because I would encounter an infinite loop there.
Can somebody give me a hint on how to progress from here? Thanks in advance
You could make willSave work, but it isn't going to be a nice bit of code to ignore all of the invalid triggers.
It's better to have a class which manages this functionality, pass in the new data value and the attribute id and allow it to do the fetch and update all of the fetched objects (and trigger the save).
I would, indeed, try to find some better way to deal with it, because actually you should't think of Core Data as of SQL with its triggers.
But actually you can indeed use willSave method and avoid infinite loop. See
NSManagedObject Class Reference willSave method
If you change property values using primitive accessors, you avoid the possibility of infinite recursion, but Core Data will not notice the change you make.
So basically in your willSave method you'll need to call some fetchRequest to get all instances of the same Entity, then loop through them and update using primitive accessor: setPrimitiveValue:forKey:
Also I would advice to verify objects in loop whether they are removed (-isDeleted) and, probably, whether that object is not your current one (by comparing managedObjectIDs)
In our app, we make use of multiple NSManagedObjectContext instances, one per thread created. So when I'm about to use any object, I always make sure that I got the object from the correct context by doing this.
object = (ObjectClass *)[[contextProvider contextForCurrentThread] objectWithID:[user objectID]];
Since I want to make sure the object is updated I go and refresh it:
[[contextProvider contextForCurrentThread] refreshObject:object mergeChanges:YES];
And my question is: If I want to traverse relationships from this object, i.e object.someRelationship, Should I also make sure that the relationship is in the current context, and refresh it? What would be the correct approach?. Refetching and refreshing every time is such a pain...
Look into nested contexts and concurrency types. They won't solve your underlying problem but they are much better than what you already have.
You need policies. To me it seems that your software (without knowing it at all) is lacking structure. Structure comes with policies.
Even if you were to refresh your objects (all of them) all the time you have serious race conditions.
Without knowing the details of your app nobody will be able to suggest anything except "think about what you do" and "introduce policies".
In my code I do a large import of thousands of objects and execute save after each object .
Do I need to turn each object into faults after saving it to save memory or will Core Data turn it automatically into faults? Unfortunately, I have not found any clue in Apple`s doc.
Thank you!
A. You can turn an object into a fault with refreshObject:mergeChanges: (NSManagedObject). This will give up strong references to related objects, so that they can be released. (If they are not holded by another reference.)
You can turn a realized object into a fault with the
refreshObject:mergeChanges: method. If you pass NO as the mergeChanges
argument, you must be sure that there are no changes to that object’s
relationships. If there are, and you then save the context, you will
introduce referential integrity problems to the persistent store.
(Link)
B. You can wipe all objects out with -reset (NSManagedObjectContext) as Daniel G said. But this really wipes out the objects, references can break.
C. I think, that there is no promise of CD to turn all saved objects into faults. (Unsaved objects cannot turn into faults.) But simply overwrite -didTurnIntoFault (NSManagedObject) to see the behavior of CD.
I'm not exactly sure what you are asking but if you have a lot of objects hanging around in your context you can always use the method -[NSManagedObjectContext reset] to reset the context and purge memory. You also don't want to do this if you have any objects that reference NSManagedObjects within the recently reset context.
I'm not sure as to the nature of your application or why you would need to execute a save on thousands of objects, it seems that you should look into using batches for your fetch requests. This way core data will guarantee that only a specified number of objects will be living in the context at any given time.
I hope this helps?