Unrelated but times is a computed property so no need to mark it as Transient. You only need to do that for stored properties that shouldn't be persisted.

I would keep the ModelContainer as a stored property and create the ModelContext in each test or even better create both the container and context objects in each test. As for the issue with your initial code, the modelContext stored property is a reference to the modelContainer.mainContect but since the modelContainer object is local to the setUp method it will be released and the reference will no longer be valid when that method exits in your second solution the modelContext is a newly created object so it will remain in memory as long as the test is running.

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.