There's a lot I don't understand about your question like what Reporter really is, how the ModelActor comes into play and what you mean with the last paragraph about the fetchAll method (did you write a "not" to much?) but one issue I see in your code is that you are passing PersistentModel objects from the detached Task to the UI which means you are passing them across actor boundaries and that is something you should not do since they are not conforming to Sendable. (Which swift version are you using and do you have any concurrency checking set?) This makes the whole solution look flawed and I would suggest that you instead fetch your objects on the MainActor using a @Query instead.

Why don't you use the @ModelActor macro instead? @ModelActor actor ConcurrentDatabase { private func save() { if self.modelContext.hasChanges { do { try self.modelContext.save() } catch { ... } } } }

Is this for a released app or only local in Xcode?

A migration is probably the best solution but if you don't want to do that you could use a custom decoding for the enum extension Kind { init(from decoder: any Decoder) throws { let container = try decoder.singleValueContainer() let rawValue = try container.decode(String.self) if let kind = Kind(rawValue: rawValue) { self = kind } else { let oldValue = rawValue.capitalized // <-- You might need to adjust this depending on how the rest of the enum looks. guard let kind = Kind(rawValue: oldValue) else { throw DecodingError.dataCorrupted(DecodingError.Context(codingPath: [], debugDescription: "Unknow kind: \(oldValue)")) } self = kind } } } Note that this will fix the value when read from storage but to actually store the new value, "Credit", each objects will need to be saved until it's persisted.

If you create a Color.Resolved value in a playground and encodes it you see you get an array of doubles rather than a structure with RGB properties and the error clearly states that an array (keyless container) is not supported. So I guess the conclusion is that Color.Resolved isn't supported by SwiftData. My playground test code and output let color = Color.red var resolvedColor: Color.Resolved resolvedColor = color.resolve(in: EnvironmentValues()) let data = try! JSONEncoder().encode(resolvedColor) print(String(data: data, encoding: .utf8)!) [1,0.23137254,0.18823528,1]

If you create the query property using a FetchDescriptor then you can set a limit for the number of rows being fetched. The drawback of this solution is that it's not a one liner so you need to do it in the init @Query private var records:[Record] init() { var fetchDescriptor = FetchDescriptor<Record>(sortBy: [SortDescriptor(\Record.date, order: .reverse)]) fetchDescriptor.fetchLimit = 7 _categories = Query(fetchDescriptor) } If you for some reason don't want to do it in the init you could declare the fetch descriptor as a static variable and then pass it to the @Query declaration

ModelContext has a property autosaveEnabled that you can set to false and then handle validation and save logic in a button action or something

I am not sure exactly what you are asking but as far as the ModelContainer yo must supply all your model types, directly or indirectly, when you create the container object

But Hashtag and HashtagFilter are two different models so why should their persistentModelID values be equal? Your variable naming confused me.

You should pass the id (persistentModelID), as you do in your code above, across actor boundaries and never the object itself.

where does the content of filterHashtags come from?

If I understand you correctly the issue is that you can't use the word throws in your code as an attribute name but maybe you can work around that by using backticks around it. I know this works fine for variables and properties and in custom types so hopefully it works within a Core Data/SwiftData context as well. So something like this should work, var `throws`: String

https://stackoverflow.com/a/79090346/9223839

I only use the @Relationship macro at one end of the relationship to avoid any issues. Maybe something has changed in the latest version that allows us to use it at both properties but in your case there is really no reason to do so.

Try to remove the database file so that SwiftData can generate a new one.