You don’t need to unwrap anything so just skip the if let self.project.subcategories?.removeAll { $0 == subcategory} calling a method on something that is nil in swift is perfectly fine

MKMapPoint doesn’t conform to Codable so you can’t use it directly in your model. One solution is to store the coordinate properties in the model instead.

An array is a value type in itself even if the elements are reference types. So if you do var myArray = project.subcategories ?? [] then any change to myArray will not affect project.subcategories but if you make a change to an object in myArray (a Subproject object?) then that object in the project.subcategories array will also be updated. So I guess the short answer is that if you want to add or remove objects to the project you need to work with project.subcategories I can't really help you with the rest because I don't really understand what you are saying in the paragraph after the last code snippet.

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.