Just like a battle plan, no codebase ever survives contact with users. As soon as users start to use an application, they want to change it. Even if the code is just for ourselves, we, also as users, will want to change things. For example, we may need to add an attribute or a new object and then restructure things to accommodate those changes. Additions and changes can be quite involved and invariably require a change in how the data is stored.
Starting with Mac OS X 10.5 Leopard and iOS 3.0, Apple has made data migration nearly trivial for users of Core Data. Taking the project outlined in Chapter 1, Building a Foundation, we’ll add some additional features to it in succeeding versions. Although a data migration works even when there’s no data stored, it’s more useful to have some data to work with. Therefore, if you haven’t added any recipes yet, I recommend doing so before we proceed.
In version 2, we’ll add the ability to tag an author to a recipe as well as tag a “last used” date. That way, we know who created the delicious dish as well as the last time we made it. We certainly wouldn’t want to accidentally make the same dish two days in a row!
In version 3, we’ll normalize the repository a bit by extracting the ingredients and forming a many-to-many relationship back to the recipes. In addition, we’ll add the concept of a shopping list to make it easier to ensure we pick up all the ingredients on our next trip to the store. Next, we’ll extract the unitOfMeasure attribute from the RecipeIngredient entity into its own entity and allow that new entity to be linked to the new ingredient entity. This step gives us one lookup list for the various units of measure and reduces the risk of human error. Lastly, we’ll remove the Meat and Fish entries from the Type attribute of the Recipe entity. Any recipe entries that are flagged with Meat or Fish will be updated to Entrée instead.