Explore Posterous

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 alloc] initWithKey:@"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];

//- (NSPersistentStore *)addPersistentStoreWithType:(NSString *)storeType configuration:nil URL:(NSURL *)storeURL options:(NSDictionary *)options error:(NSError **)error     // this is what you use to set up the database type, etc.  In this snippet I don't worry about it because I just want it to compile and display something.

// Build an NSURL to our physical database file.

NSFileManager *fileManager = [NSFileManager defaultManager];

NSString *folder = @"~/Library/Application Support/Tiny±Git/";

folder = [folder stringByExpandingTildeInPath];

if ([fileManager fileExistsAtPath: folder] == NO)

{

[fileManager createDirectoryAtPath:folder withIntermediateDirectories:NO attributes:nil error:error];

}

    

NSURL *fileURL  = [NSURL fileURLWithPath: [folder stringByAppendingPathComponent: @"TinyGit.sqlite"]];

// Now tell our NSPersistanceStoreCoordinator the type of DB you want (I'm using SQLite, you can also use XML, etc.) 

// Pass in our fileURL NSURL which is where the database will be strored. 

// There are also configurations, and options, but we can ignore this--I'll worry about those once I get this working.

[psc addPersistentStoreWithType:NSSQLiteStoreType configuration:nil URL:fileURL options:nil error:error];

[newContext save:error];

after you have created them and added them to the NSManagedObjectContext.  The interesting thing here is that the the save: actually forces all the objects within the context to be saved all at once.  It's all or nothing.  So make sure you only add the objects to the context that you want to end up in the database.

Just to verify that this actually did work, I went to my Application Support folder and sure enough there was a new Tiny±Git folder and within it a new file TinyGit.sqlite.  Just to see what got stored (if anything) I opened it up with SQLiteManager:

Compare this with the actual data model:

So, it looks like CoreData builds lots of infrastructure.  Just to see what data got stored I drilled into the data:

Well at least the data that I specified for my simple example in the previous post got saved properly, but there sure is a lot of extraneous stuff going on under the covers.

What do I conclude from all this?  I honestly am not sure. I'm feeling a bit more confident after seeing how relatively easy it is (although limiting) to save a context.  I'll have to see what it's like to actually retrieve/fetch data using CoreData.

• abduzeedo abducted by design http://abduzeedo.com/
• CGSociety society of digital artists http://forums.cgsociety.org/
• Spoonfed Design http://www.spoonfeddesign.com/

• Sparkfun http://www.sparkfun.com