Question

In Core Data of Xcode 4.3.2, an Ordered To-Many relationship is modelled with NSOrderedSet. It works well until I found the need to have repeated items in the relationship; it should really be modelled in a NSArray.

For example, in a music app, I have the following songs: SongA, SongB, SongC ,

I may want a party play list where people insert songs in any order and could be repeated. The list may look something like:

[SongC, SongC, SongA, SongC]

The way Core Data currently works, the list would become:

[SongC, SongA]

I.e., all repeated items are dropped, as it is modelled with sets.

So, coming back to my question: what is a good way to model repeated items in order in a relationship in Core Data?

Answer 1

Relationships are sets (and ordered relationships are ordered sets, but still sets); sets by definition contain unique objects. So you can’t put duplicate objects into a relationship either way.

Whether you use the ordered-relation feature or not, you’ll want to go back to the abstract ER model to find another way to turn your conceptual relationships into a Core Data model… it might help to think about how you’d do it in a plain SQL (or SQL-like) database and then come back to what Core Data does beyond SQL.

It sounds like you’re making something akin to iTunes playlists, no? A model that might work for that would go something like:

 Playlist      <--->> PlaylistEntry
 PlaylistEntry <<---> Song

The PlaylistEntry entity represents one instance of a Song‘s inclusion in one Playlist. You can have multiple PlaylistEntrys that reference the same Song in a single Playlist, and you can add other attributes to the PlaylistEntry to keep track of other things (like song order, if you’re not using an ordered relationship). As a bonus, you can use that to add other features if you like — say, to make a playlist that plays three different snippets out of one long track.