Archimage’s posterous

Contents ©2009 Archimage. All rights reserved. 
« Back to blog

Fetching from CoreData

So in the last two posts I dealt with setting up CoreData within an existing project, binding the data (NSManagedObjects to a control) and actually getting the objects to save to a file (store).  In this last entry, I'll deal with pulling data from the file in order to display it in the control.   This code assumes you have an NSManagedContext I'm calling newContext.

NSError **theError = nil;  // set up an error code

// We need to use an NSEntityDescription that the docs describe as being an abstract form of NSManagedObject. (It's like "id" is to classes.)  
// When we create an NSEntityDescription we need to map it (think cast it) to the entity in our data model we want to read within our context.
NSEntityDescription *entityDescription = [NSEntityDescription entityForName:@"Recent" inManagedObjectContext:newContext];
NSFetchRequest *request = [[[NSFetchRequest alloc] init] autorelease];  // Create a CoreData fetch request (NSFetchRequest)
[request setEntity:entityDescription];  // tell the fetch request what type of entity we want to fetch (using our NSEntityDescription)

 

 

 


// Here we need to specify our NSPredicate (think SQL SELECT predicate) to specify the subset of objects to read from our store.
// The bad news is that CoreData predicates don't use SQL syntax, which is a shame.  They use their own special syntax which makes learning a bit more problematic
// and difficult.
// I am keeping things simple here and am going to assume if I don't specify a predicate CoreData will do the sensible thing and return all objects.
// (I am just guessing here, since I didn't feel like wading thru the NSPredicate Programming Manual.)
// NSPredicate *predicate = [NSPredicate predicateWithFormat:...];
// [request setPredicate:predicate];

 

 

 


// Next, we create an NSSortDescriptor which is used to sort the object during the fetch (think an SQL ORDER BY clause.)

// Specify the property name within the entity we want to sort by (I'm using gitName) and the sort order.
NSSortDescriptor *sortDescriptor = [[NSSortDescriptor allocinitWithKey:@"gitName" ascending:YES];
[request setSortDescriptors:[NSArray arrayWithObject:sortDescriptor]];  // tell the NSFetchRequest to use the sort descriptor
[sortDescriptor release]; // clean up

 

 

 


NSArray *array = [newContext executeFetchRequest:request error:theError]; // create an array with the results of executing the fetch request on our context.
if (array != nil)
{
// move the results to our array of objects which are bound to our control.
}
else
{
// Deal with error...
}
[array release];

That's it--it works!

So, what have I learned?  Once things are set up CoreData isn't bad or overly difficult to use in this simplest of approaches. The code I've presented is pretty brute-force, but it works.  The complexity as I see it comes in learning how to manage the various layers of the graph:  the persistent store, the context, the managed objects themselves, and probably the hardest layer, the predicates.  There are some analogs to what and how SQL works, but its not as simple as SQL.  SQL is declarative and purely syntax driven.  CoreData is obviously object-oriented, but its more complex than an ORM (Object-Relational Mapping) tool such as hibernate.  

Am I going to keep using CoreData?  Yes, mainly because I got the basics working, it gives me a level of confidence, and I know I can pick up the more complex options as I need them bit by bit, and I personally have no need to learn all of CoreData at once.  

Is CoreData more cumbersome and complex than it has to be? Probably.  

Loading mentions Retweet

Comments (0)

Leave a comment...

 
To leave a comment on this posterous, please login by clicking one of the following.
Posterous-login     Connect     twitter