I want to have table in CoreData that holds a list of other CoreData objects I have accessed, for instance I have Clients and I want a table RecentClients that is simply holding this list and the date they were accessed.
Can I store the objectID and then do a fetch request based on that?
EDIT:
See Ben's answer below and then go here:
http://cocoawithlove.com/2008/08/safely-fetching-nsmanagedobject-by-uri.html
You'll want to convert the NSManagedObjectID to a string by calling its -URIRepresentation method. You can then convert the string back to an NSManagedObjectID using NSPersistentStore's -managedObjectIDForURIRepresentation: method.
If you store the strings, you should be able to do what you're describing, though you won't use a fetch request; you'll use -[NSManagedObjectContext objectWithID:]
How are you planning on storing the access date? If you make it an attribute of your Client entity, you can bump it each time the object is accessed and then use an NSFetchedResultsController that fetches Clients ordered by the access date. The downside is, of course, that you're modifying the instance every time you access it, which may not be ideal.
You could just create the RecentClients as another entity in your Core Data model. It would then have a one to many relationship with the Client entity.
Related
I have an entity in Core Data with multiple attributes. In order to increase the performance of the app, I would like to fetch only one attribute of that entity. Is that possible to do and if so, then how? Or should I just use predicates to fetch the entities that I need and from them access the values of their attributes? Thanks.
It depends on a few things; how many entities are you fetching, do you ever want anything else, what is your real performance problem?
First of all use Instruments to make sure that your problem is actually where you think it is. Core data uses faulting and batching to make it very memory and performance efficient. An entity's attribute data is not brought into memory until it is accessed.
If you really want to only fetch a single attribute from your entities then you can make a fetch request with the propertiesToFetch value set to the attributes you care about. If you do this with a managed object resultType, then AFAIK I know this will use more memory, as it will make all the result objects be a partial fault (with those properties populated) rather than full faults.
If you use the dictionary resultType, then you'll get back no managed objects at all, just an array of dictionaries with the relevant attribute populated.
You can get the single property. Here is the Apple's way
If I wanted to store a list of objectsID's of different entities in CoreData what would the data type be for the objectID so I could use it in an NSFetchRequest to later retrive the Entity?
You can not store NSManagedObjectID, but you can store the object's URI representation, and use that to retrieve the object id using NSPersistentStoreCoordinator's managedObjectIDForURIRepresentation: method. Since you seem to want a list, i would save it in a new entity and store the necessary information to identify the id and the entity name it belongs to, among other relevant information.
I have three contexts:
masterMOC - private queue tied to the persistent store, so physical saves happen here
----mainMOC - main queue tied to the UI, child of masterMOC
-------backgroundMOC - private queue, child of mainMOC
Let's see I create an Employee object on the mainMOC, then save the mainMOC. Then I save the masterMOC (which writes to disk).
Now, I've saved the Employee NSManagedObjectID in a variable, objectID. I want to get this Employee on the backgroundMOC. Does [backgroundMOC objectWithId:objectID] serve this purpose? Will it go to the persistent store and fetch this object using that method? Or will I have to preform a fetch request?
Your'e doing it right. They want you to pass objects between MOContexts using ID's. objectWithId will hit the persistent store and load the object in a fresh state.
The only gotcha you have to worry about is this case.
You fetch an object or create a new object in a MOContext.
You try pass the objectID to another context WITHOUT SAVING
The new MOContext wont know about the updates, and if you created a new object the objectID wouldn't be in the persistent store, so I think it returns nil or it's not defined.
There is a WWDC video from this year titled 'Core Data Best Practices' that talks about nested MOC's. But to answer your question, yes, objectWithId will travel up through the fewest number of MOC levels to find the object. So if you call [backgroundMOC objectWithId:objectID] and the object exists in the mainMOC, it will get it from the mainMOC without having to go all the way to the masterMOC or the database.
Do NSManagedObjects come with any kind of unique identifier?
I need to fetch a couple of objects but there is a large chance they have identical attributes, so how can I, after fetching these objects, differentiate them?
Thanks.
Yes. Every NSManagedObject has an -objectId accessor which returns an NSManagedObjectID instance. These uniquely identify the object in question. You can then retrieve the object again using either of NSManagedObjectContext's methods -objectWithID: or -existingObjectWithID:error:.
Note that if the object has not yet been saved after insertion, the object ID will be a temporary ID that will change when it's saved. You can force a persistent ID to be assigned with -[NSManagedObjectContext obtainPermanentIDsForObjects:error:], although this is just as expensive as an actual save.
I have an application that tracks a user and shows where they've been using MKOverlay. How can I save this information into Core Data so that when the user wants to see where they went yesterday they can load the map/overlay from Core Data?
I have a similar project. Mine is for cycle paths. Here is how I structure my core data model:
I use an order parameter so I can work out how the points connect up. But i think you can just check the 'ordered' property of the relationship now although im not entirely sure how it works. The min / max attributes are for more efficient searches. I store the lat long values as integers to save space after a suggestion to one of my posts. You might find this useful too.
You probably want to add some attributes to the Way such as Date.
You can save any object in a core data model, but if they are not the default type like string, int, etc. you won't be able to query on them.
So you have to construct your entity with property that you will be able to query.
So I see 2 options, you save every information in an entity, but this way you will need to alloc again all objects.
Or you only save the property you will need to query and archive your object in a transformable or in a Binary Data property.
I don't know what would be best.