Core Data Lookup Table

Question

How can I model a mutable lookup table using Core Data?

Say I have a table called "Paintings". Each painting can have one or several "Colors", such as "red", "blue", etc. The "Colors" table is therefore shared.

How can I model this?

I want to be able to modify the "Colors" table as well by adding or deleting colors as well.

Found another post that may help but still not on board yet... http://stackoverflow.com/questions/1903177/coredata-many-to-many-relationships-and-nspredicate — Christopher, Apr 23 '11 at 05:05
Ok, it appears that I simply need to create a many-to-many relationship with an inverse relationship. Is it that simple? — Christopher, Apr 23 '11 at 05:13
you have over 10 questions, and you haven't accept anyone of them. — Black Frog, Apr 23 '11 at 21:44
@Black Sorry about that. I went back and reviewed previous posts. Thanks. — Christopher, Apr 24 '11 at 05:06

westsider · Accepted Answer · 2011-04-25T17:56:19.797

2

If you want to be able to traverse from a Color to all the Painting objects that use that color, then you would want to use to-many Painting-->>Color with to-many inverse relationship Color-->>Painting. This seems likely to be what you are looking for.

If, on the other hand, you do not need to traverse from Color to Painting, then this may be one of those rare cases where you would want to forego an inverse relationship and simply have to-many Painting-->>Color.

edit

If you want to be able to delete Colors that are references by Paintings, then you probably want to keep inverse relationships between these two entities. Furthermore, you will want to define 'delete rules' on the Color-->>Painting and on the Painting-->>Color relationships. In both cases, "nullify" seems the best choice. So, when a color is deleted, all paintings that reference it will simply have that reference nullified (removed). Likewise, when a painting is deleted, all colors that referenced it will cease to reference it.

In other words, there should be no need to check for lookup failures. That said, it is always good practice to code defensively.

edited Apr 25 '11 at 17:56

answered Apr 23 '11 at 21:41

westsider

4,967
5
36
51

Thanks. I am wondering about the "lookup table" aspect. I would like to add a few color items prior to any paintings begin created so that I can provide these options to the user. If painting #1 used green when painting #2 is created I would like to "lookup" existing color values and display them. I think I may need either a separate table or a "plist" or something. – Christopher Apr 24 '11 at 05:30
I plan to create a third table with the lookup data for available colors and then reference the ID values within the Colors table. If while loading a color for a painting a lookup failure occurs than I know that this color has been deleted. There is probably a more elegant way to handle this. I hope to figure out a better way in the future. – Christopher Apr 24 '11 at 20:19
The lookup table aspect should be fairly straightforward. Basically, you will be displaying all the objects for a certain entity (i.e., Color). – westsider Apr 25 '11 at 17:35
With respect to your second comment, you will read again and again that Core Data is **not** a relational database - despite the option to store Core Data models in sqlite dbs. Take this to heart :-) and note my edit to my answer. – westsider Apr 25 '11 at 17:37
I really appreciate your responses. I think Core Data is very elegant but difficult for me to conceptualize just yet. I'll get there :-) – Christopher Apr 28 '11 at 20:33

score 1 · Answer 2 · answered Apr 23 '11 at 09:14

1

Yes, a many-to-many relation is the correct way to model this.

answered Apr 23 '11 at 09:14

loomer

2,017
1
17
11

One issue however is that I want to have a table containing "available" colors that can be selected for a painting, which can be edited (add/remove). And so each painting will have a table of colors users. Would third table be needed then? How do I keep all of the tables in synch? I think the answer to these questions will solve this problem for me. – Christopher Apr 24 '11 at 20:37

score 1 · Answer 3 · answered Apr 23 '11 at 14:13

1

You need a data model something like this:

Painting{
    name:string
    colors<<-->>Color.paintings
}

Color{
    name:string
    paintins<<-->>Painting.color
}

answered Apr 23 '11 at 14:13

TechZen

64,370
15
118
145

Core Data Lookup Table

3 Answers3