Bit of Background info, I'm using An NSOutlineView with Core Data.
This Is What I'm trying to do:
Retrieve All The objects from the Outline Views Tree Controller.
Retrieve the 'name' Property (Core Data) from each of these objects as a String.
Finally store the Strings of the 'name' Property from all the Objects in an NSArray.
For extra help, here is a Picture of my Core Data Model, http://snapplr.com/xqxv
Is this possible?
You don't need to go to the treeController to get your objects, you can query your ManagedObjectContext directly.
You essentially create and execute a fetch request, which returns an NSArray. You set the predicate for the fetch in this process as well, so if you are using it to try and filter your data this is useful as well.
Here is the example from the Apple Documentation on Fetching Managed Objects.
Related
I have a core data object RootObject.
This object has an array/relationship of other objects, ChildrenObject[].
When executing NSFetchRequest to get all my RootObjects I get an array with all of them.
The way CoreData works is that it only loads properties on demand, meaning only when I access my ChildrenObject property that property would load from the file.
Something like:
RootObject.childrenObjects.firstObject.someChildrenObjectProperty
CoreData will load someChildrenObjectProperty in memory only on first access of that property.
Is there a way to force CoreData to load it earlier, somewhere during the NSFetchRequest execution?
One option is to iterate through all of the fetched RootObject items and just access the properties but I am wondering is there some better way to do this on a CoreData level (some setup flag, fetch flag).
See NSFetchRequest.returnsObjectsAsFaults and NSFetchRequest.setRelationshipKeyPathsForPrefetching
Prerequisites:
I have 2 methods in the network API:
return list of entities (just basic info: name, id, etc.)
return detailed info about entity
The requirement is to save only objects created by processing the second request (save to sqlite) and leave non-full objects without saving.
Also, the 'main' context should contain only full objects from 1st request, and any other 'temporary' context should contain all the others objects.
I've tried to create two instances of NSPersistentStoreCoordinator and use them for different types of contexts, but it seems that for one NSManagedObjectModel can exist only one coordinator (the pointer points to the same adress).
If I understand you correctly, then I think your best option is to only create a managed object once you're sure you want it to persist in Core Data storage. You may need another layer of non-managed objects to contain data for the "non-full" entities
(This would be something like Data Transfer Objects from Java EE programming.)
You can not save indiscriminately from within the same MOC. Saving the MOC always saves everything in it.
So, you can use a separate MOC that is never saved, and then just "move" those objects to the main MOC when they are ready to be saved.
The solution that exactly solves my problem is to create two 'forks' of core data stack:
one with default config and mainContext
the second (new instance of the same NSManagedObjectModel, new
NSPersistentStore (inMemory) and new NSPersistenStoreCoordinator )
For example. if I have a chat app that uses objects like: ChatRoom and ChatMessage. (both subclasses of NSManagedObject)
And throughout the app I need to: search chat rooms / add massages / create chat rooms and messages / and any other manipulate.
Is it ok if I do everything directly with core data? I mean every time I need to search a chat room or something like that, to do it with NSFetchRequest or NSFetchedResultsController.
You can access the data whenever you need, of course. On the other hand you should try to use caching mechanism as much as possible.
For example, if you are using your data in UITableView you should defintely go with NSFetchedResultsController as it was created explicitly for UITableViews. From the apple docs on NSFetchedResultsController:
It optionally monitors changes to objects in its associated managed object context, and reports changes in the results set to its delegate (see “The Controller’s Delegate”).
It optionally caches the results of its computation so that if the same data is subsequently re-displayed, the work does not have to be repeated (see “The Cache”).
Otherwise, if you need the data just temporarily, you can access them of course using NSFetchRequest each time they are needed or cache them in your business objects if they don't change or you know their lifetime otherwise.
I'm writing an API method that returns a list of objects from a web service. This service also caches results and attempts to return the cached results (if any) before hitting the web service again. So I'm storing this list in a Core Data entity. But Core Data only allows to-many relationships to be stored in an NSSet, which does not preserve order. But I want the cached results to retain the original order (which was originally from the web service). I don't necessarily know how that order is established (so I can't sort).
So how can I preserve this order? My plan is to store a string with the object ids which I can later use to order them:
NSString *objectIds = #"1 5 2 9 4";
Is this the best way to do it?
If you can target iOS 5 then you can use the new NSOrderedSet feature for arbitrarily-ordered Core Data relationships. See the Core Data Release Notes for iOS 5 for more information about this new feature.
If you have to support iOS 4 then you will need to handle the ordering yourself. A common way to do this is to add an integer property to your model which you then need to manage yourself. You can then sort on this property when fetching your data.
Storing the order in a completely different string seems like the wrong way to do it. If the ordering is important this information should be in the model and the user should be able to query for it directly ("give me the first five objects of this particular list", or "what is the index of object foo"). Having to get a string of object IDs, parse it, and then query for certain object IDs feels very wrong to me.
Include an NSNumber id field of your own in the CoreData model in which you are storing the objects. The id will represent the ordering you want to preserve; you'll have to set it yourself, obviously. Then when you fetch the objects from CoreData you can do so sorted by that id. You may want/have to maintain somewhere the highest id value you've assigned to retain ordering correctly with subsequent web service calls and app launches.
That's a subjective question. You can also set them up as a linked list in the order you want them in.
I have a simply core data model which has two entities, a Person and a Photo. Person has a one-to-many relationship with Photos. Everything works fine, and when I access the photoList property on Person I get an NSSet with all the photos for that person.
My question is, how can I modify the managed objects in that set and the commit the results back to the core data backstore? At the moment, if I modify one of the Photo managed objects in the set they don't get saved.
The code looks something like this:
Person *myPerson = [fetchedResultsController objectAtIndexPath:indexPath];
[photosController setPhotos:[[myPerson photoList] allObjects]];
Where the set that the photosController gets is perfectly readable, but modifying its content does not update the backend store.
Thanks for all the help
Changes to managed objects are only retained in memory until you save the managed object context of the objects. Once that's done, the changes will be committed to the persistent store.