Database Reference
In-Depth Information
CHAPTER
3
Versioning and Migration
Just like a battle plan, no code base 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. Although
a data migration works even when there is no data stored, it is more useful
to have some data to work with. Therefore, if you have not added any recipes
yet, I recommend doing so before we proceed.
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
Appendix 1,
Building a Foundation
, on page 209
, we will add some additional
features to it in succeeding versions. In version 2, we will 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 will normalize the repository a bit by extracting the ingredients
and forming a many-to-many relationship back to the recipes. In addition,
we will 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 will 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 will 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.
