Learn Objective-C on the Mac - Mark Dalrymple [83]
The first thing we need to do is convert our current model to a special multi-versioned format. This will allow us to store multiple versions of our data model within our Xcode project as well as within MythBase itself. In Xcode’s navigation pane, open the Models group and select MythBase_DataModel.xcdatamodel. Now select Design➤Data Model➤Add Model Version from the menu. You should now see, in the navigation pane, that MythBase_DataModel.xcdatamodel has become MythBase_DataModel.xcdatamodeld, and has acquired a small disclosure triangle to the left of the name.
Click the triangle to open the contents, and you’ll see that it contains two versions of your model file. The one with a “2” tacked onto the end of the filename is the new one where we’ll make some changes. Select this new model file, then select Design➤Data Model➤Set Current Version from the menu. The next time you build MythBase, this new compound model, containing multiple versions of the model, will be copied into the app, and the app will try to use what you’ve set as the “current version.” Here, a problem can arise: if you just hit build at this point, it will simply copy the new multi-version model into your app, leaving the old, single-version model file there as well! This leads to an error when we run the app and it tries to load all the model files in the bundle, because it will encounter multiple models with the same version metadata (the pre-existing model, and the “version 1” in the multi-version model). The simplest way to get rid of the old model is to select Build➤Clean from the menu. Then, the next time you do a normal build (a little later on), you’ll be all set.
Adding New Entities
We’ve decided that we want to be able to keep track of not just the bands that some of our mythical people played in, but also the venues they played at, and even dates of specific gigs, so we’re going to add three new entities: MythicalBand, MythicalVenue, and MythicalGig (see Figure 8-3 for an overview).
Figure 8-3. Here are all the entities we’ll define, along with their attributes.
Make sure that the new model file is selected, then create a new entity and name it MythicalBand. Give this entity a new attribute, called “name,” set its type to String, and click to turn off the Optional checkbox and turn on the Indexed checkbox.
Now create another new entity named MythicalVenue, also with a single String attribute called “name,” which should also be Indexed but not Optional.
Finally, create an entity called MythicalGig. Unlike the other entities we’ve added, gigs don’t have names. The only distinguishing characteristics of a MythicalGig are its relationships to a band and a venue (which we’ll get to in a bit) and the date of the performance. Add a new attribute, name it performanceDate, and change its type to Date. You can leave the performanceDate set to be Optional (since the exact dates of some ancient gigs may have gone down the memory hole), and there’s no need to turn on Indexing for it either.
Add Relationships
Now it’s time to add relationships, so that each object can be attached to other relevant objects. We’re going to define a one-to-many relationship from MythicalBand to MythicalPerson, a one-to-many relationship from MythicalBand to MythicalGig, and finally another one-to-many relationship from MythicalVenue to MythicalGig. See Figure 8-4 for an overview.
Figure 8-4. The model will look like this after you add the relationships.
At this point we should clarify our terminology a bit. In Core Data, each relationship is actually a one-way affair, and they’re not defined in terms like “one-to-many,” “one-to-one,” “many-to-many,” and so on. Instead, each Core Data relationship is either “toone” or “to-many.” In order to create what in normal usage (if you accept the notion that any form of computer programmer jargon is “normal”) is called a “one-to-many relationship” in Core Data, you actually have to create two relationships: a “to-many” relationship rooted at the first entity and ending at the second,