Monday, August 2, 2010

Core Data Odds and Ends

I've been doing a fair bit of work with Core Data lately, and have picked up a few tricks to make my life easier, so I thought I'd share.

Mo' Power


Back in the EOF days, there was a great little piece of third-party software called EOGenerator that implemented something called the generation gap design pattern. Essentially, this little program would create your custom subclasses of EOGenericRecord (EOF's equivalent of NSManagedObject) for you. It wouldn't just create that, though, it would actually create two classes for each entity in your EOModel.

One of these two classes was yours to modify as you saw fit. It would never get overwritten even if you ran the EOGenerator script again, over and over. The other class contained all the generated code derived from your EOModel and was designed not to be touched by the programmer. You had your class, EOGenerator had its class, and you could both work without any fear of stepping on each other's toes. You could add attributes and entities to your data model and regenerate the machine-readable classes without any chance of losing your custom validation or methods. It was nice.

Wolf Rentzsch has re-implemented this idea for Core Data, and the result is called MOGenerator. If you spend any time with Core Data and aren't familiar with MOGenerator, go become familiar with it. It will make your life much, much, much better.

SQLite to Check Data


The default persistent store type for Core Data under iOS is a SQLite store, which means that Core Data keeps all of its data inside of a single SQLite database in your application's /Documents folder. Now, the format of the persistent store is undocumented and you should never, ever, ever, ever, never change data in the persistent store or make any assumptions about how Core Data stores the data. That's part of why we use Core Data: It's an abstraction layer that lets us not worry about the underlying storage details.

But, sometimes, it can be really helpful to know whether data is getting into the persistent store or not. I often work on my data model before my user interface, so being able to peek in the data store to make sure all is well is really helpful.

The first thing you might want to consider doing, if you plan to do that, is to create a SQLite config file. This is a file of commands that will execute whenever you launch SQLite. To do that, simply create a file called .sqliterc in your home directory. Here's what mine looks like:
.mode column
.header on
.table
In mine, the first line tells SQLite to print the column names when I issue a SELECT command. The second line tells SQLite to present the data in tabular form. The last line prints out a list of all the tables in the database before it shows me the SQL command prompt. That's handy given that the table names don't usually exactly match your entity or class names.

Once you have a config file in place, you can open up any persistent store using the sqlite3 command in Terminal.app, like so:
sqlite3 MyApplication.sqlite
You can't, of course, execute this directly against database files on your phone, but you can do it in the simulator as well as on files copied from your phone using Xcode's Organizer. If you're using the simulator, you can look for your SQLite databases at the following location:
/Users/[your account name]/Library/Application Support/iPhone Simulator/[SDK version #]/Applications/[application UUID]/Documents/[Application Name].sqlite


When I log into a database with my SQLite config file, this is what I see:
-- Loading resources from /Users/jeff/.sqliterc
ZHERO ZPOWER Z_METADATA Z_PRIMARYKEY
SQLite version 3.6.12
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite>
Notice that it has dumped the names of all my tables. It's pretty easy to figure out which table holds what data once they're right in front of you. The example above is the persistent store from the SuperDB application from More iPhone 3 Development. The Hero entity managed objects are stored in ZHERO and the Power entity managed objects are stored in ZPOWER. To look at the contents of a table, you just need to execute a SQL SELECT command. The simplest is just SELECT * FROM TABLENAME;, which prints the entire contents of the table to the console, like so:
sqlite> select * from ZPOWER;
Z_PK Z_ENT Z_OPT ZHERO ZSOURCE ZNAME
---------- ---------- ---------- ---------- ---------- ----------
1 2 2 1 Mutation Fire
sqlite>
The format of the data is pretty easy to figure out but, again, you really should look and not touch. It'd be very easy to accidentally destroy a persistent store. A seemingly inconsequential change could get the metadata out of whack and prevent your app from using the persistent store any more.

Better Descrption


I noticed a few days ago that Wil Shipley was complaining about the fact that many of Apple's delivered UIKit and Foundation objects have not overridden the -description method. This method is important because it's the one that is used in format strings, NSLog(), and when you type the po command in GDB. Instead of getting a meaningful description of many delivered objects, you instead get the class name and memory address of the instance, which is what NSObject's implementation provides, which isn't very much help while debugging.

Unfortunately, NSManagedObject is one of the many, many classes that doesn't have its own meaningful implementation of -description. That doesn't mean you can't provide one, though.

One thing you can do is to create an abstract subclass of NSManagedObject and put the -description method there. If you then subclass this abstract class, all of your managed objects will inherit the method from the abstract class. If I have other common functionality, I'll often do exactly that. But if I don't (and often you won't) I personally hate to clutter up my object hierarchy to add debugging tools. So I actually will cheat and do something you're not really supposed to do, which is override a method using a category. The reason it's bad to do this is because the Objective-C language does not specify which method should be used, which can lead to unpredictable behavior. But, when a class inherits a method from a superclass, I've found that overriding it in a category always works. I'm not suggesting you should do this in a shipping app, however. I wrap my method in pre-compiler definitions so that it doesn't get compiled into the release version of my application.

My version of -description assumes you're generating properties for your managed objects (I always do) and also assumes you're using custom subclasses (but you are, because you're using MOGenerator, right??). The method iterates over all the properties of the class and all its superclasses up to NSManagedObject, then prints them to the console. The categories I use look like this:
#if DEBUG
@implementation NSObject(MCManagedObjectDebug)
+ (NSMutableArray *)MCproperties
{
NSMutableArray *properties = nil;

if ([self superclass] != [NSManagedObject class])
properties = [[self superclass] MCproperties];
else
properties = [NSMutableArray array];


unsigned int propCount;
objc_property_t * propList = class_copyPropertyList([self class], &propCount);
int i;

for (i=0; i < propCount; i++)
{
objc_property_t oneProp = propList[i];
NSString *propName = [NSString stringWithUTF8String:property_getName(oneProp)];
if (![properties containsObject:propName])
[properties addObject:propName];
}

return properties;
}

@end


@implementation NSManagedObject(MCManagedObjectDebug)
- (NSString *)description
{
NSArray *properties = [[self class] MCproperties];
NSMutableString *ret = [NSMutableString stringWithFormat:@"%@:", [self className]];
NSDictionary *myAttributes = [[self entity] attributesByName];

for (NSString *oneProperty in properties)
{
NSAttributeDescription *oneAttribute = [myAttributes valueForKey:oneProperty];
if (oneAttribute != nil) // If not, it's a relationship or fetched property
{
id value = [self valueForKey:oneProperty];
[ret appendFormat:@"\n\t%@ = %@", oneProperty, value];
}


}

return ret;
}


@end
#endif
The +MCProperties method uses the Objective-C runtime to discover and iterate over properties in the class definition, including @dynamic properties that were created at runtime. Because the property runtime calls do not include properties inherited from parent classes, the method acts recursively, iterating up the object hierarchy until it gets to NSManagedObject. The actual -description method simply prints out each of the attributes and the value currently stored for that attribute for this object instance. Once you do this, if you use NSLog() or po, the result is much richer information about the objects getting printed to the console. This version ignores relationships and fetched properties, but it wouldn't be hard to add those in if you needed them.



15 comments:

RobW said...

Thanks for sharing Jeff. Would you agree that your custom description has side-effects of faulting in property values (and relationships if you chose to log them) that would otherwise not be taking up memory?

I think the utility of the NSManagedObject description method is very useful, as it doesn't cause side effects, leaving the logged object in the same state as before it was "described". If you have conditional debug logging (Build configuration or macro-defined), a full description side effect may lead to confusion. I like your description method.. I think it would be quite handy while inspecting objects in gdb.

Charles Watts said...

Great tips... It's always nice to find ways to make Core Data easier to use...

Regarding inspecting the SQLite store, I've used 'Core Data Editor' with great success.

Give it the model file and the db and it lets you inspect all the objects stored in a nice graphical way.

Jérôme Laheurte said...

Nice stuff. Being a newbie at Core Data, the first time I encountered the description problem, I just used a category on the generated class. Works fine for me.

Hunter Hillegas said...

From the Core Data Programming Guide:

"You are discouraged from overriding description—if this method fires a fault during a debugging operation, the results may be unpredictable—and initWithEntity:insertIntoManagedObjectContext:. You should typically not override the key-value coding methods such as valueForKey: and setValue:forKeyPath:."

FYI, YMMV.

David den Boer said...

One thing that I find very useful in debugging my CoreData data issues is an app called CoreData Editor (http://christian-kienle.de/CoreDataEditor/). It uses a model file and the sqlite db to help you view/edit persistent stores.

DadGuy said...

I wish I had had moGenerator a couple of months ago when I was trying to do my first complex core data project. I apparently did things as a hybrid between the 10.4 way and the new way, which almost always worked but sometimes didn't. Frustrating. That would have saved me a lot of time. Live and learn I suppose.

I have used SQLite browser to good effect when checking data in core data.

佳陳容 said...

良言一句三冬暖,惡語傷人六月寒。......................................................................

Stela James said...

Many many thanks to you for this great share.

home jobs

Jeff LaMarche said...

Hunter:

Yep, you are discouraged from doing it, which is precisely why I do it in DEBUG builds only. I have not had any problems using it this way and it has saved me a ton of time typing in

po [myObject myAttribute]

tons of times in the debugger.

Sometimes you have to roll a hard six. :)

Jeff LaMarche said...

RobW:

Yes, it almost certainly triggers faulting for the object. That's specifically why I don't log relationships because you could end up with a cascade effect. Faulting in a single object shouldn't be a problem, and never has been for me.

But, there's always a chance it could cause problems while debugging, but I've found it to be far more help then harm so far.

Instead of wrapping it in a #IF DEBUG, you could do a different value like #IF CORE_DATA_DEBUG and then only define that when you needed to use it.

Gamal Sabry said...

hiii

http://www.coveingweb.com

ebaum said...

So I looked at using MOGenerator and ended up using a category on the generated class instead. It seems to cover a lot of the same ground. What do you see as the advantage of MOGenerator over this approach?

Samantha said...

Thanks for the great tips. I always enjoy reading your blog, and you share a lot of great ideas!

SEO Services Consultants said...

Nice information, many thanks to the author. It is incomprehensible to me now, but in general, the usefulness and significance is overwhelming. Thanks again and good luck! Web Design Company

Daniel said...

As far as I can tell, NSManagedObject's -describe method already prints out all attributes and relationships, and also shows when the object itself or relations are still faults. Maybe this was added in a recent iOS update (maybe iOS 4.1 or so)?