CODEWITHSUNDEEP
swiftcore-data
Crew3339
Crew3339

Reputation: 51

Core Data: Transformable Type or To-Many Relationship?

I'm a rookie and having a hard time wrapping my head around core data.

I have created an app that works fine saving to the file manager, but gets slow with lots of data in it. I would like to upgrade this to core data.

I've successfully created some entities out of my basic classes that persist just fine, but when I have a class that has properties of other classes as arrays, I'm not sure what direction to go to have it save in core data.

Simple Example:

class Student {
  let name: String
  let markbook: [Markbook]
}

class Markbook {
  let name: String
  let components: [MarkbookComponent]
}

Each student instance should have their own markbook and each markbook will have multiple markbook components that can have individual student marks updated.

For my core data Student entity, what would be the right approach: do I make markbook transformable type to achieve an array of markbooks, or do I make a Markbook entity with a to-many relationship to Student? Does that to-many relationship give each student their own individual markbook?

Upvotes: 3

Views: 956

Answers (1)

pbasdf
pbasdf

Reputation: 21536

Use relationships; your problem is what they were invented for.

(Although it's possible to use transformable attributes to represent arrays of objects:

  1. it's not possible to have arrays of other NSManagedObjects (CoreData gets confused);
  2. you have to maintain or compute inverse relationships yourself (in your example, if you have a Markbook and wish to know which Student it relates to, you'd have to scan through all the Student objects to locate it. If you create an inverse relationship in CoreData, it will be populated and managed for free by CoreData); and
  3. transformable attributes cannot be "inspected" as part of a predicate for a fetch request. Hence if you wish to fetch all Markbooks with a MarkbookComponent titled "English", you'll have to fetch ALL Markbooks first, and then filter them in memory.)

As regards the cardinality of the relationships, if each Student can have at most one Markbook, then the relationship can be "to-one" (and will be defined in the class as a property of type Markbook rather than an array [Markbook]). Assuming each Markbook likewise relates to only one Student, the inverse relationship will also be "to-one".

As each Markbook can have more than one MarkbookComponent, model the relationship as "to-many" (which will then be defined in the class as a set of Markbooks). I'm not sure from your description whether a MarkbookComponent can relate to only one Markbook, or more than one: model the inverse relationship as "to-one" or "to-many" as appropriate.

Upvotes: 3

Related Questions