• Choose a category
• All
• Classic-Fiction

Now look at the checkboxes just below the Name field, labeled Optional, Transient, and Indexed. The meaning of Optional is clear enough. Having it checked means that users can choose to not enter a value for that attribute when creating or editing an object. As for the others, checking Transient configures things so that this attribute isn’t saved along with the other data, while checking Indexed turns on indexing for the attribute, enabling speedy search of a Core Data storage back-end based on this attribute. For the name attribute, make sure that Indexed is checked, and that the others are not.

Below the checkboxes, you specify the attribute’s type using a popup list. Select String from the popup list, and you’ll see some additional options appear in the space just below it, where you can specify simple validation rules such as the string’s length. Here you can also specify the default value, which will appear whenever a new MythicalPerson instance is created. Enter “Name” for the default value, leaving the other fields blank.

Now let’s move on to the details attribute, which is meant to hold a textual description of the MythicalPerson in question. Click the “+” button below the Property table view, choose Add Attribute, and change the new attribute’s name to “details.” We’re going to configure this one a little differently than the name attribute. It should be a String (chosen from the popup list), and the Indexed checkbox should be checked, but in this case the Optional checkbox should also be checked, so that users can choose to leave this field empty if they want. Also, we’ll leave the default value blank.

Now we’ll tackle MythicalPerson’s numeric attributes: divinity, goodness, and power. Make a new attribute and name it “divinity,” and this time configure the checkboxes so that it’s optional, but neither transient nor indexed (because we don’t anticipate any real need to search for MythicalPersons using the divinity value as a search parameter). Then click the Type popup list, and choose Integer 16, the smallest integer type support by Core Data. You’ll see the display change to show some additional configuration that applies to the chosen type. Here we can set up some automatic validation rules by specifying min and max values, and also specify the default value for this attribute.

In Table 7-1, we defined divinity as an integer value from 0 to 100, the idea being to place the character somewhere on a scale between human and godlike. For example, the Greek god Zeus would have a divinity value of 100, his son Hercules (whose mother was a normal human) would have 50, and a normal human (like, again, Hercules’ mother) would have 0 divinity. By specifying min and max values for the attribute, we let Core Data help us out, ensuring that no invalid values for these attributes can be saved. Enter 0 for the min value, 100 for the max value, and 50 for the default value. See Figure 7-4 to see some entity/attribute editing in progress.

Figure 7-4. This is what editing an entity in a Core Data model file looks like.

Now we’re going to create the other two numeric values, goodness and power. These also express characteristics of each MythicalPerson on a scale from 0 to 100, and will have the exact same configuration as divinity (except, of course, for the name of the attribute itself). The easiest way to make these, giving them the exact same options, is to select the divinity attribute by clicking on it in the table view, then copy it (⌘C), then paste it (⌘V) twice, resulting in two new attributes named “divinity1” and “divinity2.” Rename those “goodness” and “power”, and that’s it; those two new attributes will have the same min and max values as the original.

Attributes for Unsupported Types

The last attribute left to configure is the depiction attribute. As we mentioned earlier, the depiction attribute is meant to store an image, and Core Data doesn’t know anything about the NSImage class normally