“SwiftData inheritance relationship”

I had that guess too, however, myEntity.isDeleted is false when this occurs. Also, I am fetching the model right before deleting it. Here I have just noticed something weird in the documentation, namely that model(for:) creates an unsaved instance if called with an unknown ID. So I tried the same with registeredModel(for:), but I get the same error https://developer.apple.com/documentation/swiftdata/modelcontext/model(for:)

I am not completely clear what your question is, but based on the description, it seems to be related to the order of SwiftData array, and so I'd start with that. In a SwiftData model that contains an array, the array element can be a Codable type or a SwiftData model, as shown below: @Model class Department { @Relationship(deleteRule: .cascade, inverse: Employee.department) var employees: [Employee] = [Employee]() // Relationship var aliasNames: [String] = [] // `String` is Codable ... } @Model class Employee { var department: Department? ... } Here employees is a SwiftData relationship, and aliasNames is an attribute of a string array. Every time you fetch Department and access the attribute and relationship, the elemet order of department.aliasNames is the same, but that of department.employees is not. The reason is that SwiftData uses Core Data as its default store, and in Core Data, a too-many relationship is expres

Thanks for provide the code. I don't see it has anything that should trigger a failure though. If you can elaborate a bit more about what failure you expect to see, I may take another look. To comment your following description: When I was saving a duplicate field value, it was not failing, it was replacing the current with a new record, thus it remained unique because the old record was replaced. This behavior is as-designed, and is known as upsert. For a model that has a unique attribute, when you add a new object and there already exists another object that has the same value for the unique attribute, SwiftData updates the existing object with the new one. No error will be triggered in this case. For models that don't have any unique attribute, objects are identified by persistentModelID, which is managed by SwiftData. You can add multiple objects that have same values for all the attributes you define, without triggering any conflict. Best, —— Ziqiao Chen  Worldwide Developer Relations.

import SwiftData //Model one: type of contract, i.e. Firm Fixed Price, etc @Model final class TypeOfContract { var contracts: [Contract] var typeName: String var typeCode: String var typeDescription: String init(contracts: [Contract], typeName: String = , typeCode: String = , typeDescription: String = ) { self.contracts = contracts self.typeName = typeName self.typeCode = typeCode self.typeDescription = typeDescription } } //Model two: the Contract @Model final class Contract { var contractType: TypeOfContract? var costReports: [CostReport] var contractNumber: String var contractName: String var startDate: Date var endDate: Date var contractValue: Double var contractCompany: String var contractContact: String var contactEmail: String var contactPhone: String var contractNotes: String init(contractType: TypeOfContract? = nil, costReports: [CostReport], contractNumber: String = , contractName: String = , startDate: Date = .now, endDate: Date = .now, contractValue: Double = 0.0, contractCompany: String

On a CI infrastructure, we connect nodes through SSH and launch automated app testing. So, I'm going to start with a very short answer, then try and give a much longer answer. So, the short answer first: open /Applications/Pages.app Great! You should do that! /Applications/Pages.app/Contents/MacOS/ Yes, you really shouldn't do this. Long Answer: Let's start with what this actually does: open /Applications/Pages.app Part of our system’s fundamental design is the idea of execution contexts. If you want to learn more about some of the details, the great classic, TN2083: Daemons and Agents, is probably the best entry point. However, summarizing the most relevant details... First off, for our purposes, there are two relevant execution contexts: The global or system session. This is running all the time and cannot present any kind of user interface. This is where daemons run. User or login sessions (there can be more than one if multiple users are logged in). Logging in creates a login session, and logging out dest

Your code doesn't include the SwiftData model type (TypeOfContract), and hence isn't runnable. If you can provide a runnable code example, with detailed steps to reproduce the issue, I'd be interested in taking a look. Best, —— Ziqiao Chen  Worldwide Developer Relations.

Part 2... That leads to here: and how can I make sure my app will be allowed to update when I need it too. The first thing I'd do here is shift the way you're thinking about this issue from how do I remove/bypass quarantine to how do I make sure my update process always works. You've focussed on quarantine because it's a fairly common edge case; however, the problem with focussing on solving it is: The system’s behavior is opaque and undocumented. This means, as you're already experiencing, it's hard to make this work right at all, and even if you succeed, it's very likely that something will change in the future, leaving you back with the same problem. Quarantine is only one failure source of many. For example, what if the actual problem is that the app is being run from a read-only location like a network share? That second point is what makes this problem so tricky. The full range of valid macOS configuration is so large that it's effectively impossible to fully test or predict. This means you end up trapp

Is there a better channel or documentation to understand the details of relationship between the GUID for unifiedContacts identifier vs contactRelations identifier?