Yeah, this is an interesting topic. Consider the following flow: In a background task that runs for long time, you fetch a SwiftData model object and hold it for later use. In the main queue, the object is deleted via user interaction. In a background task, you access the object. Based on the current implementation of SwiftData, step 3 will trigger an error because the object was deleted. In the Core Data world, you can use query generations to guarantee the object being valid in step 3, as discussed in Accessing data when the store changes. In the case where, from a managed object context pinned to a generation, you change a piece of data that has been changed, saving the context triggers a conflict, which you can handle via NSMergePolicy. SwiftData doesn't have query generations, and so I don't see an ideal pattern to handle the kind of issue. I may consider the following: a. Avoid accessing a same piece of data simultaneously by shorten the time window. Concretely: In the backgro
Topic:
App & System Services
SubTopic:
iCloud & Data
Tags: