开发者

Assigning two CoreData relationships (with inverse relationships) to the same entity

开发者 https://www.devze.com 2023-02-13 09:04 出处:网络
Within my CoreData model, I have an Event entity which is paired with specific Activity entities. Currently, I have an optional relationship between Event and Activity called LatestActivity. I\'m now

Within my CoreData model, I have an Event entity which is paired with specific Activity entities. Currently, I have an optional relationship between Event and Activity called LatestActivity. I'm now looking to create a new relationship specifically for the NextActivity but realise it is impossible to set the inverse of both relationships to the same entity.

I understand why this is not possible due to the SQlite backing store, but am wondering how best to go about it. After a bit of Googling the best solution I've seen is as follows: setup a one-to-many relationship called Activities within my Event entity, and then setup helper functions to fetch and return the latest and next activities.

This is good in that it allows me to attach multiple activities to events in the future, but I'm confused as to where and how to implement these helper functions. The next and latest events would be fet开发者_如何学编程ched by way of comparing an NSDate within the Activity entity using the following logic:

  • The latest activity represents the most recent date before the current date
  • The next activity represents the next activity with a date greater than now

But what's the cleanest way to search CoreData for these entities, and where should I carry out that search?


I may not understand you when you say that you "realise it is impossible to set the inverse of both relationships to the same entity." Consider this model:

Assigning two CoreData relationships (with inverse relationships) to the same entity

It is clear that it is possible to have multiple bi-directional relationships between two entities. In this case, there are three bi-directional relationships:

  1. Event's activities <-->> Activity's event (which is to-many from Event's perspective)
  2. Event's lastActivity <--> Activity's inverseLastActivity
  3. Event's nextActivity <--> Activity's inverseNextActivity

Of course, you would still need to keep lastActivity and nextActivity up to date - and, perhaps, your suggestion of deriving that in real time may be more robust.

I have lingering concern that I have misunderstood your question...

0

精彩评论

暂无评论...
验证码 换一张
取 消