Advanced DataModel in Xcode with CoreData

I have a question regarding a rather advanced DataModel which I would like to use with CoreData.

Before I get into details about what I did so far, I will describe what I want to do.

I have a List of Hotel Guests that stay in one Room and have Preferences. Once ready the user should select a guest and see the data and should also be able to add new guest, select the room (maintained also by application) and select their preferences (where the user can also add new preferences). The guest can have no or many preferences.

So here is what I have so far. I created 3 Entities : - Rooms with roomnumber - Preferences with name - GuestInfo with name -> with these Relationships room (Destination Rooms) and prefs (Destination Preferences with "To-Many Relationship")

Now, I did all this and created the Managed Object Classes. So far so good. The problem is that I get some warnings.

1. GuestInfo.room -- relationship does not have an inverse
2. GuestInfo.prefs -- to-many relationship does not have an inverse: this is an advanced setting开发者_C百科 (no object can be in multiple destinations for a specific relationship)

Is this just a warning I can ignore ? I mean for the room, there is always just one room number for each guest, but there can be more guests in one room so can not put any inverse relationship here. Also for the preferences, there can be no or more preferences for each guest.

In Objective-C warnings should NEVER be ignored. When dealing with Core Data this is doubly true. Treat every warning as an error at runtime.

As for inverse relationships, you should ALWAYS have inverses. If you don't then performance will suffer and data integrity is at a high risk.

These warnings can be ignored (see this question), but it's easy to just add the inverse relationships to make Core Data happy. Add a relationship to Room to GuestInfo, and one to Preference to GuestInfo, and make sure you select the inverse. I assume these would be one-to-one, since you would only have one guest info per room. This might have a side effect that when you set the room on a guest info, any other guest info with that room will be removed. If that's undesirable you can make the relationship a many-to-one.