Many years ago I put an attribute named throws in a core data entity.
Now I want to extract the data and move it to a new swift data with more function. I try to rename the entity to avoid compile problems with throws being a swift keyword, now banned as a SwiftData field.
I need a code path to extract from the original core data using swift. The SwiftData macros seem to choke on the throws keyword and substitute blanks.
DB rename of the attribute still uses the original throws name at the code level.
iCloud & Data
RSS for tagLearn how to integrate your app with iCloud and data frameworks for effective data storage
Post
Replies
Boosts
Views
Activity
I've been working with SwiftData and encountered a perplexing issue that I hope to get some insights on.
When using a @Model that has a one-to-many relationship with another @Model, I noticed that if there are multiple class variables involved, SwiftData seems to struggle with correctly associating each variable with its corresponding data.
For example, in my code, I have two models: Book and Page. The Book model has a property for a single contentPage and an optional array of pages. However, when I create a Book instance and leave the pages array as nil, iterating over pages unexpectedly returns the contentPage instead.
You can check out the code for more details here. Has anyone else faced this issue or have any suggestions on how to resolve it? Any help would be greatly appreciated!
I dont understand. How does using appended help here? I am not adding anything to the array. Here is the summary
The following code defines two SwiftData models: Book and Page. In the Book class, there is a property contentPage of type Page, and an optional array pages that holds multiple Page instances.
@Model
class Book {
var id = UUID()
var title: String
var contentPage: Page
var pages: [Page]?
init(id: UUID = UUID(), title: String, contentPage: Page) {
self.id = id
self.title = title
self.contentPage = contentPage
contentPage.book = self
}
func addPage(page: Page) {
if pages == nil {
pages = []
}
page.book = self
pages?.append(page)
}
}
enum PageType: String, Codable {
case contentsPage = "Contents"
case picturePage = "Picture"
case textPage = "Text"
case blankPage = "Blank"
}
@Model
class Page {
var id = UUID()
var pageType: PageType
var pageNumber: Int
var content: String
var book: Book?
init(id: UUID = UUID(), pageType: PageType, content: String, pageNumber: Int) {
self.id = id
self.pageType = pageType
self.pageNumber = pageNumber
self.content = content
}
}
Observed Behavior:
With the code above, I created a Book instance and populated all fields except for the pages, which was left as nil. However, when I attempt to iterate over the pages, I receive the contentPage instead. This indicates that there may be an issue with how SwiftData handles these associations.
Expected behavior - when iterating over pages I should not see contentPage since it is a separate property
I frequently referred to Apple’s tutorial on SwiftData in Swift, but recently I haven’t been able to access it. Is there a reason why?
Create, update, and delete data - De velop in Swift Tutorials
https://developer.apple.com/tutorials/develop-in-swift/create-update-and-delete-data
I am currently developing an iOS app with a new feature that utilizes Quick Start for data migration between devices. We are testing this in a test environment using an app distributed via TestFlight.
However, we are encountering an issue where the app installed on the pre-migration device (distributed via TestFlight) does not transfer to the post-migration device. Could this issue be related to the fact that the app was distributed via TestFlight? Is there any restriction where only apps released via the App Store can be migrated using Quick Start?
We would appreciate it if you could provide some insights into the cause of this issue and any alternative testing methods.
Is this Relationship correct? Does this cause a circular reference? This runs on 18 but crashes on 17 in the swift data internals.
@Model
final class Item {
@Attribute(.unique) var id: UUID
var date: Date
@Relationship(deleteRule: .nullify, inverse: \Summary.item) var summary: Summary?
init(date: Date = Date.now) {
self.id = UUID()
self.date = Calendar.current.startOfDay(for: date)
self.summary = Summary(self)
}
}
@Model
final class Summary {
@Attribute(.unique) var id = UUID()
@Relationship var item: Item?
init(_ item: Item) {
self.item = item
}
}
I have an app that uses Core Data. I'm switching to SwiftData but it looks like the sqlite files are stored in separate places in the application file directory so my SwiftData files aren't reading the CoreData store. I'm not sure why it's not reading from the same location. Is there something I'm missing? Here's an example of the paths that I see when I write information to the debug console:
SwiftData Path: file:///Users/dougthiele/Library/Developer/CoreSimulator/Devices/52CE32F8-F6A9-4825-8027-994DBE47173C/data/Containers/Data/Application/63E9B61D-64B8-4D2D-A02C-3C306688F354/Documents/[Data File Name].sqlite
Core Data Path:
file:///Users/dougthiele/Library/Developer/CoreSimulator/Devices/52CE32F8-F6A9-4825-8027-994DBE47173C/data/Containers/Data/Application/96A5961B-54DD-43A9-A4C3-661B439D91AE/Documents/[Data File Name].sqlite
I'm seeing these errors in the console when calling ModelContainer(for:migrationPlan:configurations) for iOS 18:
error: Attempting to retrieve an NSManagedObjectModel version checksum while the model is still editable. This may result in an unstable verison checksum. Add model to NSPersistentStoreCoordinator and try again.
CoreData: error: Attempting to retrieve an NSManagedObjectModel version checksum while the model is still editable. This may result in an unstable verison checksum. Add model to NSPersistentStoreCoordinator and try again.
Is this anything to be concerned about?
(Side note: "version" is misspelled in "verison checksum")
I have two contexts, MAIN and VIEW. I construct an object in MAIN and it appears in VIEW (which I use to display it in the UI). Then I delete the object in MAIN. Because the UI holds a reference to the object in VIEW, VIEW records it as a pending delete (Problem 1). I don't understand why it does this nor can I find this behaviour documented. Docs for deletedObjects say "objects that will be removed from their persistent store during the next save". This has already happened!
(Problem 2) Then I rollback the VIEW context, and the object is resurrected. awakeFromInsert is called again. While the object (correctly) does not appear in a freshly executed fetch request, it does appear in the @FetchRequest of the SwiftUI View which is now displaying stale data. I cannot figure out how to get SwiftUI to execute the fetch request again (I know I can force regeneration of the UI, but would like to avoid this).
This is self-contained demonstration of the problem that can be run in a Playground. Press Create, then Delete (note console output), then Rollback (note console output, and that element count changes from 0 to 1 in the UI)
import CoreData
import SwiftUI
@objc(TestEntity)
class TestEntity : NSManagedObject, Identifiable{
@NSManaged var id : UUID?
override func awakeFromInsert() {
print("Awake from insert")
if id == nil {
// Avoid resetting ID when we resurrect the phantom delete
self.id = UUID()
}
super.awakeFromInsert()
}
class func add(in context: NSManagedObjectContext) -> UUID {
let id = UUID()
context.performAndWait {
let mo = TestEntity(context: context)
mo.id = id
}
return id
}
class func fetch(in context: NSManagedObjectContext) -> [TestEntity] {
let fr = TestEntity.fetchRequest()
return try! context.fetch(fr) as! [TestEntity]
}
}
class CoreDataStack {
// Main is attached to the store
var main : NSManagedObjectContext!
// View is a child context of main and used to display the UI
var view : NSManagedObjectContext!
// Set up a simple entity with an ID attribute
func getEntities() -> [NSEntityDescription] {
let testEntity = NSEntityDescription()
testEntity.managedObjectClassName = "TestEntity"
testEntity.name = "TestEntity"
let idAttribute = NSAttributeDescription()
idAttribute.name = "id"
idAttribute.type = .uuid
testEntity.properties.append(idAttribute)
return [testEntity]
}
init() {
let model = NSManagedObjectModel()
model.entities = getEntities()
let container = NSPersistentContainer(name: "TestModel", managedObjectModel: model)
let description = NSPersistentStoreDescription()
description.type = NSInMemoryStoreType
container.persistentStoreDescriptions = [description]
container.loadPersistentStores { desc, error in
if error != nil {
fatalError("Failed to set up coredata")
}
}
main = container.viewContext
view = NSManagedObjectContext(concurrencyType: .mainQueueConcurrencyType)
view.automaticallyMergesChangesFromParent = true
view.parent = main
}
func create() {
let entityId = TestEntity.add(in: main)
main.performAndWait {
try! main.save()
}
}
func delete() {
main.performAndWait {
if let mo = TestEntity.fetch(in: main).first {
main.delete(mo)
try! main.save()
}
}
self.view.perform {
// We only find that we have a pending delete here if we hold a reference to the object, e.g. in the UI via @FetchRequest
if(self.view.deletedObjects.count != 0) {
print("!!! view has a pending delete, even though main has saved the delete !!!")
}
}
}
func rollback() {
self.view.perform {
self.view.rollback()
// PROBLEM We now have a resurrected object. Note that awakeFromInsert
// was called again.
}
}
}
import SwiftUI
import PlaygroundSupport
let stack = CoreDataStack()
struct ContentView: View {
@FetchRequest(sortDescriptors: []) private var entities: FetchedResults<TestEntity>
@State var renderID = UUID()
var body: some View {
VStack {
Text("\(entities.count) elements")
Button("Create") {
stack.create()
}
Button("Delete") {
stack.delete()
}
Button("Rollback") {
stack.rollback()
// PROBLEM After rollback we get the element displaying in
// the UI again, even though it isn't present in a freshly
// executed fetch request.
// The @FetchRequest is picking up the resurrected TestEntity in view
// But not actually issuing a fetch.
self.renderID = UUID()
entities.nsPredicate
}
}.id(renderID)
}
}
//stack.execute()
let view = ContentView()
.environment(\.managedObjectContext, stack.view)
PlaygroundPage.current.setLiveView(view)
I have an iOS app that writes files to its iCloud ubiquity container. The container is specified in Signing & Capabilities as iCloud.com.myappbusiness.myappid where "com.myappbusiness.myappid" is the bundle identifier. It works most of the time but for some users (less than 1%) it stops working at some point, most likely after any update of my app. Device reboot or app reinstallation does not help. What seems to help is turning off iCloud for the app in the iOS Settings (at which point the app saves files to the device locally) and then turning it on again.
I cannot replicate the issue and have to rely on user feedback. I have tried various fixes over the past half a year, added retries after timeout, error handlers, tracing, etc. But the error always appears to someone after another app update.
I have narrowed it down to the three lines of code below that check for the existence of the app iCloud container:
NSFileManager* fileManager = [[NSFileManager alloc] init];
NSURL* containerUrl = [[fileManager URLForUbiquityContainerIdentifier:nil]
URLByAppendingPathComponent:@"Documents"];
BOOL doesExist = [fileManager fileExistsAtPath:containerUrl.path];
doesExist returns NO when the issue happens. I.e. the app does not see its container and it looks like it does not exist. The folder should exist as this happens to long term users that have used the app before. Regarding the containerUrl, I can see it in the log that I get from the affected users and it is the correct path to the container, e.g. /private/var/mobile/Library/Mobile Documents/iCloud~com~myappbusiness~myappid/Documents
I have tried the code above as it is and also within a file coordinator handler:
[[[NSFileCoordinator alloc] initWithFilePresenter:nil] coordinateWritingItemAtURL:targetFileUrl
options:NSFileCoordinatorWritingForReplacing error:&error
byAccessor:^(NSURL * _Nonnull newURL) { ... the code here ... }];
I have run out of ideas what else to try. Is there anything obviously wrong with this approach or am I missing something in the code here? Is this a permission issue? Do I need to recreate the Documents folder if it's not accessible?
Currently, I am planning to add a new feature to my app that allows multiple users to collaboratively manage a single legder. Initially, I chose SwiftData with iCloud for development, so I wanted to inquire whether SwiftData currently supports data sharing among multiple users through iCloud. If it does not, should I transition entirely to Core Data, or is it feasible to allow Core Data and SwiftData to work together?
Presently, I am encountering an issue with SwiftData. For instance, I have a SwiftData class Ledger that encompasses an array of SingleTransaction, which is also a SwiftData class.
Here is the question: when I save a Ledger, how can I discern that the .NSManagedObjectContextDidSave notification was triggered by saving the Ledger and not by saving a SingleTransaction? This distinction is crucial to circumvent unnecessary updates. I attempted the following syntax, but Xcode indicates that Cast from NSManagedObject to unrelated type Ledger always fails.
List {...}
.onReceive(
NotificationCenter
.default
.publisher(for: .NSManagedObjectContextDidSave)
.receive(on: DispatchQueue.main),
perform: { notification in
if let userInfo = notification.userInfo,
let updatedObjects = userInfo[NSUpdatedObjectsKey] as? Set<NSManagedObject> {
if updatedObjects.contains(where: { $0 is Ledger }) {
fetchLedgers()
}
}
}
)
What can I do?
Dear community !!!
I'm brand new in SwiftUI development. I created an app, I was almost at the end with fine tuning when I got weird behaviours with the iOS 18 version when using Swift Data.
I think I'm part of the problem but I can not figure out how to solve it.
I've searched, spent so many hours and feel a bit disappointed not succeeding.
Here is my first problem :
I've two models :
@Model
class Song: Codable {
var uuid: UUID = UUID()
var text: String = ""
var creationDate: Date = Date.now
var updatingDate: Date = Date.now
var status: Int = 0
var nbRead: Int = 0
var speed: Float = 0.5
var language: String = ""
enum CodingKeys: CodingKey {
case uuid, text, creationDate, updatingDate, status, nbRead, speed, language
}
@Relationship(inverse: \Genre.songs)
var genres: [Genre]?
...
}
and
@Model
class Genre {
//var uuid: UUID
var name: String = ""
var color: String = "Red"
var songs: [Song]?
init( name: String, color: String) {
//self.uuid = uuid
self.name = name
self.color = color
}
}
I want to list all songs organised by sections :
import SwiftData
import SwiftUI
struct SongsListView: View {
private var searchingText: String
@Environment(\.modelContext) private var modelContext
@Query(sort: \Genre.name) private var genres: [Genre]
@Query var songs : [Song]
init(searchText: String)
{
if !searchText.isEmpty {
let predicate = #Predicate<Song> { song in
song.text.localizedStandardContains(searchText)
}
_songs = Query(filter: predicate)
}
searchingText = searchText
}
var body: some View {
HStack{
List{
if !songs.isEmpty {
ForEach(genres, id: \.name){ genre in
Section(header: Text(genre.name)){
ForEach (songs){song in
if let songGenres = song.genres {
if songGenres.contains(genre){
NavigationLink {
SongView(song: song)
} label: {
Text(song.text)
}
}
}
}
}
}
.onDelete { indexSet in
indexSet.forEach { index in
let song = songs[index]
modelContext.delete(song)
}
}
Section(header: Text("Without Genre")) {
ForEach (songs){song in
if let songGenres = song.genres {
if songGenres.isEmpty{
NavigationLink {
SongView(song: song)
} label: {
Text(song.text)
}
}
}
}
.onDelete { indexSet in
indexSet.forEach { index in
let song = songs[index]
modelContext.delete(song)
}
}
}
}
}
.scrollContentBackground(.hidden)
}
}
}
On iOS 17, creating a new song adds it directly to the list in the Without Genre section.
On iOS 18, it takes around 30 seconds to be added.
I did a video, and I have a demo project to illustrate if necessary.
Thanks a lot for any hint, advice !
I'm using Swift Data for an app that requires iOS 18.
All of my models conform to a protocol that guarantees they have a 'serverID' String variable.
I wrote a function that would allow me to pass in a serverID String and have it fetch the model object that matched. Because I am lazy and don't like writing the same functions over and over, I used a Self reference so that all of my conforming models get this static function.
Imagine my model is called "WhatsNew". Here's some code defining the protocol and the fetching function.
protocol RemotelyFetchable: PersistentModel {
var serverID: String { get }
}
extension WhatsNew: RemotelyFetchable {}
extension RemotelyFetchable {
static func fetchOne(withServerID identifier: String, inContext modelContext: ModelContext) -> Self? {
var fetchDescriptor = FetchDescriptor<Self>()
fetchDescriptor.predicate = #Predicate<Self> { $0.serverID == identifier }
do {
let allModels = try modelContext.fetch(fetchDescriptor)
return allModels.first
} catch {
return nil
}
}
}
Worked great! Or so I thought...
I built this and happily ran a debug build in the Simulator and on devices for months while developing the initial version but when I went to go do a release build for TestFlight, that build reliably crashed on every device with a message like this:
SwiftData/DataUtilities.swift:65: Fatal error: Couldn't find \WhatsNew. on WhatsNew with fields [SwiftData.Schema.PropertyMetadata(name: "serverID", keypath: \WhatsNew., defaultValue: nil, metadata: Optional(Attribute - name: , options: [unique], valueType: Any, defaultValue: nil, hashModifier: nil)), SwiftData.Schema.PropertyMetadata(name: "title", keypath: \WhatsNew., defaultValue: nil, metadata: nil), SwiftData.Schema.PropertyMetadata(name: "bulletPoints", keypath: \WhatsNew.)>, defaultValue: nil, metadata: nil), SwiftData.Schema.PropertyMetadata(name: "dateDescription", keypath: \WhatsNew., defaultValue: nil, metadata: nil), SwiftData.Schema.PropertyMetadata(name: "readAt", keypath: \WhatsNew.)>, defaultValue: nil, metadata: nil)]
It seems (cannot confirm) that something in the release build optimization process is stripping out some metadata / something about these models that makes this predicate crash.
Tested on iOS 18.0 and 18.1 beta.
How can I resolve this? I have two dozen types that conform to this protocol. I could manually specialize this function for every type myself but... ugh.
I have a @Model class that is comprised of a String and a custom Enum. It was working until I added raw String values for the enum cases, and afterwards this error and code displays when opening a view that uses the class:
{
@storageRestrictions(accesses: _$backingData, initializes: _type)
init(initialValue) {
_$backingData.setValue(forKey: \.type, to: initialValue)
_type = _SwiftDataNoType()
}
get {
_$observationRegistrar.access(self, keyPath: \.type)
return self.getValue(forKey: \.type)
}
set {
_$observationRegistrar.withMutation(of: self, keyPath: \.type) {
self.setValue(forKey: \.type, to: newValue)
}
}
}
Thread 1: EXC_BREAKPOINT (code=1, subcode=0x1cc165d0c)
I removed the String raw values but the error persists. Any guidance would be greatly appreciated. Below is replicated code:
@Model
class CopingSkillEntry {
var stringText: String
var case: CaseType
init(stringText: String, case: CaseType) {
self.stringText = stringText
self.case = case
}
}
enum CaseType: Codable, Hashable {
case case1
case case1
case case3
}
I have an app that uses Member as a @Model Class name. When I installed Xcode 16, Member was not allowed and failed in the Build, so I had to rename the class. If I pass this patch to the app store, my users will lose data. Do you have any suggestions?
I'm working on an app that is using Core Data. I have a custom big number class that boils down to a double and an integer, plus math functions. I've been using transformable types to store these big numbers, but its forcing me to do a lot of ugly casts since the number class is used throughout the application. I figure I can either have my stored values be named differently (e.g. prefix with underscore) and have a computed variable to cast it to the correct type, or find some way to move the big number class to being an NSManagedObject. The issue with this is that the inverse relationships would be massive for the big number class, since multiple entities use the class in multiple properties already. Would it be recommended that I just keep using Transformable types and casts to handle this, or is there some standard way to handle a case like this in Core Data relationships?
I'm managing the database with SQLite in Flutter.
I want to enable iCloud backup and restore on the Swift side when called from Flutter.
I am using the following source code, but it is not working.
What could be the cause?
Could you provide a method and countermeasure?
private func saveFileToICloud(fileName: String, localDatabasePath: String, result: @escaping FlutterResult) {
guard let containerName = Bundle.main.object(forInfoDictionaryKey: "ICLOUD_CONTAINER_NAME") as? String else {
result(FlutterError(code: "NO_ICLOUD_CONTAINER", message: "iCloud container is not available", details: nil))
return
}
guard let containerURL = FileManager.default.url(forUbiquityContainerIdentifier: containerName) else {
result(FlutterError(code: "NO_ICLOUD_CONTAINER", message: "iCloud container is not available", details: nil))
return
}
let fileURL = containerURL.appendingPathComponent(fileName)
let sourceURL = URL(fileURLWithPath: localDatabasePath)
do {
if FileManager.default.fileExists(atPath: fileURL.path) {
try FileManager.default.removeItem(at: fileURL)
}
try FileManager.default.copyItem(at: sourceURL, to: fileURL)
result("File saved successfully to iCloud: \(fileURL.path)")
} catch {
result(FlutterError(code: "WRITE_ERROR", message: "Failed to write file to iCloud", details: error.localizedDescription))
}
}
private func readFileFromICloud(fileName: String, localDatabasePath: String, result: @escaping FlutterResult) {
let containerName = ProcessInfo.processInfo.environment["ICLOUD_CONTAINER_NAME"]
guard let containerURL = FileManager.default.url(forUbiquityContainerIdentifier: containerName) else {
result(FlutterError(code: "NO_ICLOUD_CONTAINER", message: "iCloud container is not available", details: nil))
return
}
let fileURL = containerURL.appendingPathComponent(fileName)
let sourceURL = URL(fileURLWithPath: localDatabasePath)
do {
if FileManager.default.fileExists(atPath: sourceURL.path) {
try FileManager.default.removeItem(at: sourceURL)
}
try FileManager.default.copyItem(at: fileURL, to: sourceURL)
result("File restored successfully to sqlite: \(sourceURL.path)") } catch {
result(FlutterError(code: "READ_ERROR", message: "Failed to read file from iCloud", details: error.localizedDescription))
}
}
Hello,
I'm currently developing an app using SwiftData.
I want the app to use CloudKit to sync data, so I made sure all my model properties are optional.
I've defined a Codable enum as follows:
enum Size: Int, Codable {
case small
case medium
case large
}
I've defined a Drink SwiftData model as follows:
@Model
class Drink {
var name: String?
var size: Size?
init(
name: String? = nil,
size: Size? = nil
) {
self.name = name
self.size = size
}
}
In one of my Views, I want to use a @Query to fetch the data, and use a Predicate to filter the data. The Predicate uses the size enumeration of the Drink model. Here is the code:
struct DrinksView: View {
@Query var drinks: [Drink]
init() {
let smallRawValue: Int = Size.small.rawValue
let filter: Predicate<Drink> = #Predicate<Drink> { drink in
if let size: Size = drink.size {
return size.rawValue == smallRawValue
} else {
return false
}
}
_drinks = Query(filter: filter)
}
var body: some View {
List {
ForEach(drinks) { drink in
Text(drink.name ?? "Unknown Drink")
}
}
}
}
The code compiles, but when I run the app, it crashes with the following error:
Thread 1: Fatal error: Couldn't find \Drink.size!.rawValue on Drink with fields [SwiftData.Schema.PropertyMetadata(name: "name", keypath: \Drink.name, defaultValue: nil, metadata: nil), SwiftData.Schema.PropertyMetadata(name: "size", keypath: \Drink.size, defaultValue: nil, metadata: nil)]
How can I filter my data using this optional variable on the Drink model?
Thanks,
Axel
Building an app, which worked fine until I updated to XCode 16.
The app parses data and saves it to SwiftData, and later that store is used for filtering in data.
If I create the store on iOS 18, the store created has issues with relationships, so filtering is not working (I hope that will be fixed in iOS 18.1), so I need to create the store on iOS 17.5.
But before saving the parsed objects to the SwiftData (store), I do the checking for dupes. And after Xcode 16 update that is not working anymore on iOS 17.5, (but this part is working fine under iOS 18):
Here is my object:
import Foundation
import SwiftData
@Model
class CaliberData: Identifiable {
var id: UUID = UUID()
var sizeHeights: [SizeObject]
var featuresABCDIds: [Int]
init(
id: UUID,
sizeHeights: [SizeObject],
featuresABCDIds: [Int],
) {
self.id = id
self.sizeHeights = sizeHeights
self.featuresABCDIds = featuresABCDIds
}
extension CaliberData: Equatable {
static func == (lhs: CaliberData, rhs: CaliberData) -> Bool {
lhs.featuresABCDIds == rhs.featuresABCDIds
&& lhs.sizeHeights == rhs.sizeHeights
}
}
SizeObject if needed:
@Model
class SizeObject: Identifiable, Equatable {
@Attribute(.unique)
var id: Float
@Relationship(inverse: \CaliberData.sizeHeights)
private(set) var caliberDataSizesX: [CaliberData]?
init(_ size: Float) {
self.id = size
}
}
When I am doing the caliberData1 == CaliberData2 comparison to remove dupes before inserting to the SwifData modelContext I am getting exception, and Xcode shows it inside getter part of this expanded section under sizeHeights definition:
@storageRestrictions(accesses: _$backingData, initializes: _sizeHeights)
init(initialValue) {
_$backingData.setValue(forKey: \.sizeHeights, to: initialValue)
_sizeHeights = _SwiftDataNoType()
}
get {
_$observationRegistrar.access(self, keyPath: \.sizeHeights)
return self.getValue(forKey: \.sizeHeights)
}
set {
_$observationRegistrar.withMutation(of: self, keyPath: \.sizeHeights) {
self.setValue(forKey: \.sizeHeights, to: newValue)
}
}
}
Following is the stacktrace:
#1 0x00000001cc168928 in ___lldb_unnamed_symbol4385 ()
#2 0x00000001cc163f34 in ___lldb_unnamed_symbol4354 ()
#3 0x00000001cc165fc4 in ___lldb_unnamed_symbol4369 ()
#4 0x00000001cc169dd4 in ___lldb_unnamed_symbol4403 ()
#5 0x00000001cc123854 in SwiftData.PersistentModel.getValue<τ_0_0, τ_0_1 where τ_1_0: SwiftData.RelationshipCollection, τ_1_1 == τ_1_0.PersistentElement>(forKey: Swift.KeyPath<τ_0_0, τ_1_0>) -> τ_1_0 ()
#6 0x0000000105eda3b0 in CaliberData.sizeHeights.getter at /var/folders/5y/vv3v98ms7jj3z4kj0f3d6f9h0000gq/T/swift-generated-sources/@__swiftmacro_11CaliberDataC11sizeHeights18_PersistedPropertyfMa_.swift:9
#7 0x0000000105ef1a84 in static CaliberData.== infix(_:_:) at ...
My assumption is that "it" thinks that object is already inside the modelContext, when it's actually not yet inserted there and should act like regular class (by regular, I mean - like not marked with @Model macro).
How can I do objects comparison on iOS 17.5 with Xcode 16 (before they are inserted in modelContext)? Any other options?
Anyone getting "Failed to execute query" when querying a Record type in CloudKit Console?
just a simple query on all records