0

I have 2 entities in which totally 12 properties are there of 3 variations of min, max and average of some particular type of fields. Hence I refactored the 2 entities into 3 entities making the 3rd entity as 'Values' which contains 3 properties i.e min, max and average. And reduced the 12 properties into 4 relationships. Here's a replica of my models as an example in the image below.

enter image description here

As you can see I have one-to-one unidirectional relationship with the 3rd entity. However Xcode keeps on complaining about 'Inverse' relationship.

enter image description here

As per me I can add 4 relationships in 'Values' and update all to become 'inverse', however this doesn't seem to be the right solution as when the second entity gets tied to the 'Values', it will have additional 3 nil relationships and whereas in case of first it will have 1 additional nil relationship. Both of these are unnecessary.

Refactoring 'Values' and splitting it into two similar entities also is not a good solution either I believe.

Hence can anyone suggest me what is the right approach or best practice to solve this problem. Let me know if I'm unclear anywhere while describing my issue.

Rameswar Prasad
  • 1,331
  • 17
  • 35

2 Answers2

2

Based on your description, I would undo the refactoring and go back to using properties instead of relationships. You're adding complexity for no real benefit, and the Values entity is (as you're finding) too generic to really be useful or meaningful. This refactoring isn't serving any useful purpose; don't fix it, revert it.

Tom Harrington
  • 69,312
  • 10
  • 146
  • 170
  • Yes I agree with the fact that it's too generic. Let me wait for few more better solutions until tomorrow, else have to either revert or refactor in a better way. – Rameswar Prasad Feb 15 '17 at 16:44
  • Downvoted, this isn't a solution or really an answer to OP's problems, this is a comment with an opinion. Please use the comment section for these purposes. –  Feb 15 '17 at 17:06
  • @Sneak the question was `what is the right approach or best practice to solve this problem` which this answer provides. You may disagree with this answer but it is an answer. – Martin Feb 15 '17 at 17:41
  • @Martin So the answer to **to solve this problem.** is **don't fix it, revert it** . Great to know what an answer is in your opinion. However, SO answers should provide a solution to the problem, and not an opinion, you can however add a solution AND an opinion. The point with SO is for the question/answer to be able to help people running in to the same problem. Maybe somebody wants 3 entitys with 3 relationships because that is their use-case they see fit? However, your opinion is valid as an opinion and i'm glad you posted it in the comment section and not as an answer. –  Feb 15 '17 at 18:51
  • @Sneak I answered the question as asked in the last paragraph. Helping someone implement a bad design decision is not useful or worthwhile. – Tom Harrington Feb 15 '17 at 20:08
0

You should look into Weak Relationships (Fetched Properties) for how to manage relationships correctly and the solution for your error code.

Most object relationships are inherently bidirectional. If a Department has a to-many relationship to the Employees who work in a Department, there is an inverse relationship from an Employee to the Department that is to-one. The major exception is a fetched property, which represents a weak one-way relationship—there is no relationship from the destination to the source.

Also, if you want to make things easier, you should look into (if possible) avoid 3 objects and have a single object, or two objects, with the propertiesToFetch of the NSFetchRequest in mind. This way you can fetch your Entity , keep the properties in a single Entity, but only fetch the properties you want and avoid the overhead and memory consumption of fetching properties you are not going to use.

Whichever fits your needs, you have the options. GL