I've once again read through the Apple developer Core Data documentation and found it lacking when it comes to the graphical Xcode 4 editor when creating SQLLite entities much as I found it lacking when IB was separate in Xcode 3.
Three tables:
- ZipData
- LocationData
- CrossReference
CrossReference has the primary key of ZipData and LocationData so I only need to query CrossReference to get all zips for locations or all locations for zips. This means of course a to-many relationship on both ZipData and LocationData (and perhaps on CrossReference?).
What I have (that isn't working) relationship-wise is this :
- ZipData has a relationship "locations" that points to LocationData and is inverse
- LocationData has a relationship "zipsCodes" that points to ZipData and is inverse
- CrossReference table has two relationships, one to ZipData (and is inverse) and one to LocationData (and is inverse).
I'm not sub-classing any of the entities as NSManagedObjects just yet. I am simply doing the code below in the viewDidLoad method, just to see if what I have setup works.
// test/learn the core data frame work
NSManagedObjectContext *context = [self managedObjectContext];
NSManagedObject *locationData = [NSEntityDescription
insertNewObjectForEntityForName:@"LocationData"
inManagedObjectContext:context];
[locationData setValue:@"Testville" forKey:@"City"];
[locationData setValue:@"United Tests" forKey:@"Country"];
[locationData setValue:@"County of Test" forKey:@"County"];
NSManagedObject *zipCodeData = [NSEntityDescription
insertNewObjectForEntityForName:@"ZipCo开发者_如何学CdeData"
inManagedObjectContext:context];
[zipCodeData setValue:[NSNumber numberWithDouble:1111.00] forKey:@"Income"];
[zipCodeData setValue:[NSNumber numberWithDouble:22.00] forKey:@"LandArea"];
[zipCodeData setValue:@"23060" forKey:@"ZipCode"];
NSError *error;
if (![context save:&error]) {
NSLog(@"Whoops, couldn't save: %@", [error localizedDescription]);
}
NSFetchRequest *fetchRequest = [[NSFetchRequest alloc] init];
NSEntityDescription *entity = [NSEntityDescription
entityForName:@"CrossReference" inManagedObjectContext:context];
[fetchRequest setEntity:entity];
NSArray *fetchedObjects = [context executeFetchRequest:fetchRequest error:&error];
for (NSManagedObject *info in fetchedObjects) {
NSLog(@"LocationId: %@", [info valueForKey:@"LocationDataId"]);
NSManagedObject *details = [info valueForKey:@"details"];
NSLog(@"ZipId: %@", [details valueForKey:@"ZipCodeDataId"]);
}
[fetchRequest release];
I don't understand how to setup these relationships and not sure how to trust that somehow the primary keys are setup and the entities just kind of find their way together.
I'm getting nothing back in the logs even though when I view the simulators sqllite db I see the test entities have been persisted (but nothing in CrossReference). I know I'm missing something relationship wise but I can't put my finger on it.
Your major problem is revealed by the bolded phrases below:
I've once again read through the Apple developer Core Data documentation and found it lacking when it comes to the graphical Xcode 4 editor when creating SQLLite entities much as I found it lacking when IB was separate in Xcode 3.
Three tables:
ZipData LocationData CrossReference
CrossReference has the primary key of ZipData and LocationData so I only need to query CrossReference to get all zips for locations or all locations for zips.
There is no such thing as SQLite entities
and Core Data does not have tables or primary keys.
Core Data is not SQL. Entities are not tables. Objects are not rows. Attributes are not columns. Relationships are not joins. Core Data is an object graph management system that may or may not persist the object graph and may or may not use SQL far behind the scenes to do so. Trying to think of Core Data in SQL terms will cause you to completely misunderstand Core Data and result in much grief and wasted time.
You are making a mistake common to people skilled in SQL. You are assuming that Core Data is a lightweight object wrapper around procedural SQL. It is not. The SQLite store is but one of four persistence options and the data model itself is wholly independent of which persistence option you choose i.e. the same model will work with all types of stores. The stores are just different means of archiving and de-archiving (freeze drying and rehydrating) a graph of live objects. How a specific graph gets persisted is a behind the scenes implementation detail you can ignore in the vast majority of cases. Simply forget everything you know about SQL because it won't help you understand Core Data.
Your specific problem here is that you never set the relationships between the objects. You need to create a CrossReference
object and set it's relationships, thusly;
NSManagedObject *crossReference = [NSEntityDescription
insertNewObjectForEntityForName:@"CrossReference"
inManagedObjectContext:context];
[crossReference setValue:locationData forKey:@"location"];
[crossReference setValue:zipCodeData forKey:@"zipCode"];
The context will ensure that the reciprocal relationship is set on the related LocationData
and ZipData
objects.
The key to mastering Core Data is to ignore the form of persistence and to instead think only in terms of objects with attributes and relationships. Once you really internalize that concept, then every thing falls into place easily.
精彩评论