Why entity cannot have uniqueness constraints with to-one mandatory inverse relationship?

Short answer:

The underlying problem is most likely caused by the sqlite standard. I'm not sure about that. How ever, it's very likely that it is because of the limitations of sqlite. I found some posts on the internet, where people had issues with multiple constraints on one table and thats most likely the reason why the two-table workaround works.

Long answer:

It's pretty late, but I hope it helps anyway.

This occurs when your Entity has an unique constraint and a mandatory relation. I guess it's because of the added unique constraint behaviors in iOS 9.0. However you can solve this in two ways:

You remove the unique constraint or make the relation optional. You could handle an optional relation in code. But it won't be a nice solution.

OR

You can use a workaround. You can have both. You can create a super class having a unique constraint. However this won't work without problems, too.

Let's you have three entities. A, B and C.

A is your super class and B is a sub class of A and C is a sub class of A, too. A has an unique constraint on it's property primaryKey. When saving instances of B and C, you can not have a B and C with the same primaryKey. Because CoreData will manage both as A.

You could change A to have two Properties:

• int: originalPrimaryKey (NO unique constraint)
• string: primaryKey (unique constraint)

You can now map your primaryKeys to originalPrimaryKey and when setting the originalPrimaryKey you could set the string primaryKey property to CLASS_NAME.{originalPrimaryKey}. This would allow you to have the behavior, you would expect. But you have to add a workaround for primaryKeys.