Question

This is a conceptual question about how best to organize relationships between NSManagedObjects in Core Data.

How do you organize your entities in Core Data when there appear to be circular dependencies?

For example, let’s say I’m doing a social recipe app. This app allows you to organize meals based on who’s making each recipe and who’s buying each ingredient. In addition, each recipe is created by a different person. I thus propose the following NSManagedObjects followed by their respective attributes and relationships:

Chef = uniqueID (String), username (String), skill (String)
>> recipesToMake = (to-many) Recipe
>> ingredientsToBuy = (to-many) Ingredient

Recipe = uniqueTitle (String), authorID (String)
>> ingredients = (to-many) Ingredient

Ingredient = name (String), calories (Integer 64)

QUESTIONS

[_] If I have multiple Chef‘s working on the same recipe, does that mean multiple copies of the same Recipe object are stored in Core Data, each belonging to a separate Chef? If so, is that alright? If not, how to I go about making a single Recipe object in Core Data and having multiple Chef‘s point to it, when Chef itself can point to-many Recipe objects via recipesToMake?

[_] If given a recipe, how would I check which Chef‘s are assigned to it? Would I fetch those Chef objects in Core Data that point to a Recipe object with the given uniqueTitle attribute?

[_] Since a Chef object can point to-many Recipe objects, is it thus correct to store the author of each Recipe as an attribute on Recipe containing the author’s uniqueID? I initially would have thought to create a relationship from Recipe to-one Chef, but that then creates yet another circular dependency between Chef and Recipe objects.

[_] Yet again, if Chef can point to-many Ingredient objects via ingredientsToBuy and Recipe can point to-many Ingredient objects via ingredients, does that many there will be multiple copies of the same Ingredient object in CoreData?

[_] If I were to allow Recipe objects to have an arbitrary number of authors, how would I go about implementing that? Using a relationship with Chef objects would seem to create a circular dependency, while using attributes connected to Chef uniqueID‘s would seem to require pre-specifying a maximum number of authors per Recipe object.

Answer 1

The term “circular dependency” is used negatively here, but what you are really referring to in Core Data is relationships and inverse relationships, and its actually recommended.

Circular dependencies are unwanted when you are architecting a system of classes that rely on each other too much and in both directions, also known as coupling. They are indeed not desirable, but it relates more to code flow and logic, not when dealing with data relationships.

Here are answers to your questions:

1. The onus is on you to the enforce uniqueness of Recipes in your code, which means you have to define the qualities that make two recipes the “same” recipe. You can go so far as to compare each Ingredient of the recipe, or it may suffice that the uniqueTitle is all thats needed to compare for uniqueness of recipe. With that, you can implement the “update or create” design pattern, where you first look up the Recipe by its primary key, which in the simpler scenario is the uniqueTitle. If it already exists, then you can simply read and/or update that object. Otherwise create it as a new managed object. Subsequent queries for it will fetch the just-created object. Each chef then can have a relationship to that single Recipe object.

2. For every relationship, it’s a good practice to also define the inverse relationship. In the Recipe object, call it something like “ChefsMaking”, which is probably a to-many relationship that points to Chef objects. (They combine to make a “many-to-many” relationship). In Xcode, theres a drop down box for each relationship where you can set up its inverse.

3. I do believe its possible to create more than one relationship that references the same type of object. Here there are two types of relationship that point from Recipe to Chef. One is “ChefsMaking”, a to-many relationship. The other is “Author”, a to-one relationship, the inverse of which would be a to-many “RecipesAuthored” relationship in the Chef object.

4. The same principles from answer 1 apply here. Define uniqueness of an Ingredient, and have your Chefs and Recipes point to an Ingredient either by fetching one that already exists (by its primary key) or creating a new one.

5. Simply rename your relationship Authors, and make it a to-many relationship.

Hope this helps!