Well a simplified version could be to only keep the current super class Item and use a Boolean (or an enum) property to define if it’s a collection or a link.

You haven’t provided the details about CollectionItem which seems to be the class that causes the crash but I must say that it’s a very strange design you have where the superclass both has a children property of self and is being inherited. Do you really need such a complex solution?

Could it be that you create multiple instances of the ModelContainer?

I would recommend using a struct instead that mirrors the properties in the model, no more work really than working with duplicate properties and probably much easier to handle state changes etc.

An easier solution is to wrap the string in a struct and use an array of that custom struct instead. Make sure the struct conforms to Codable. Ideally we should be able to have just an array of String but that isn’t possible currently

It looks much better but be careful with those delete rules, why do you want to delete the teacher and students if you delete a class? Both the teacher and students might be in other classes, right? I would use nullify in most cases an only use cascade if I know that was exactly what I wanted to do.

Some will be easy to get like all teachers for a school but others will require a little more work. One important thing to remember is that you add relationships to define your models and how they relate and not for helping with some queries you might want to implement. That said, one further relationship to consider is between School and Student so that a student can only take classes that belongs to the school they are assigned to.

You haven't told us exactly what your issue is but something I spotted with your design that I don't think is correct is the relationship between Teacher and Student. As I see it your design will be simpler and more correct if you complete remove that relationship. A teacher holds (has) one or more classes A student attends (has) one or more classes So indirectly you have the relationship between Teacher and Student via the SchoolClass model. A bit unrelated but I prefer to use the @Relationship macro with the inverted argument for one of the relationship properties since it makes the code clearer for me (and it is also helpful for SwiftData)

Why not use the objects (Category) directly in the predicate since they conform to Equatable?

When a model object is saved its identifier is changed from a temporary one to a permanent one (so I assume the hash values also changes) so this is most likely what cases an issue here with the picker. One way to work around this is to call save() directly after the inserts.

You don’t need to use the @Attribute macro for your properties at all unless you want to give them some custom behavior.

The same. Just make sure you always initialize the to-many properties to an empty array as you have done in your example

Initializing the ModelContainer in an onAppear of a view is too late, you need to do it directly in MyApp where yo declare the property itself.

You could enable Core Data debug logging (also used by SwiftData) to see if that gives you any important information, see https://www.hackingwithswift.com/quick-start/swiftdata/using-launch-arguments-to-debug-swiftdata-and-core-data

You could make the model properties private and rename them and then add computed properties with the old name that you can access from outside the class. var someString: String could be replaced with private var someStringStored: String? var someString: String { get { someStringStored ?? "" } set { someStringStored = newValue } }