title: mergepolicy on a to-one relationship with uniquing constraints erases object instead of updating it
body: <p>I've just encountered an odd Core Data behaviour. For context, my app consumes a JSON API by making my various Core Data entities decodable. Users can track TV Shows they're interested in so I have a <code>Show</code> entity with a to-many relationship to <code>Season</code>. The inverse is a to-one relationship since a season can only belong to a single TV show. I have a uniquing constraint on a <code>remoteID</code> property for both <code>Show</code> and <code>Season</code> entities.</p>
  <p>At launch, I request updates on the user's TV shows. Due to the way I ingest the data, the JSON response essentially creates duplicates, then on save the <code>NSMergePolicy.mergeByPropertyObjectTrump</code> would ensure duplicates are merged thanks to the uniquing constraint.</p>
  <p>This has been working fine for regular properties and to-many relationships but now that I'm syncing seasons, the to-one relationship deletes seasons with every other sync. For example:</p>
  <p>Sync 1:</p>
  <ul>
  <li><code>Show A</code> has 4 seasons locally.</li>
  <li><code>Show A</code> is fetched with 4 seasons.</li>
  <li>After context is saved <code>Show A</code> now has 0 seasons</li>
  </ul>
  <p>Sync 2:</p>
  <ul>
  <li><code>Show A</code> now has 0 seasons locally.</li>
  <li><code>Show A</code> is fetched with 4 seasons.</li>
  <li>After context is saved <code>Show A</code> now has 4 seasons</li>
  </ul>
  <p>Note that if I set my inverse relationship to be to-many (from <code>Season</code> to <code>Show</code>), this behaviour does not happen. It's ok for my purposes but not ideal as it could create issues down the line.</p>
  <p>This is my interpretation of what happens:</p>
  <ul>
  <li>Core Data first merges the duplicated <code>Season</code> objects.</li>
  <li>Because a <code>Season</code> can only have 1 <code>Show</code>, one of the duplicated <code>Show</code> will lose its link to that <code>Season</code>.</li>
  <li>Core Data then merges the duplicated <code>Show</code> objects.</li>
  <li>At that point, one of them has seasons and the other one doesn't.</li>
  <li>Core Data decides that the one without seasons is the most recent &quot;change&quot; and thus the one that should be committed to the store.</li>
  </ul>
  <p>That last point I am unsure about and doesn't quite make sense to me. I guess my question is: does anyone knows precisely what is happening here and could confirm or correct my explanation? Also, if there's any way around it I don't know, I'd be extremely grateful!</p>