“SwiftData inheritance relationship”

Just to add that SwiftData + CloudKit uses NSPersistentCloudKitContainer under the hood, and so the technotes my colleague mentioned apply to your topic. Specifically, you can use CloudKit Console to determine if the data is synchronized to CloudKit. From there, you can determine if the issue happens on the exporting or importing side, and go ahead to capture and analyze a sysdiagnose, as described in the Capture and analyze a sysdiagnose section. Best, —— Ziqiao Chen  Worldwide Developer Relations.

So, let me start here: Why are all logs attributed to the kernel? Because that's where the logs came from. More specifically, the os_log function you are calling in DriverKit is not the same os_log function that exists in userspace. It actually does IPC into the kernel, which then logs out through the kernel’s logging infrastructure. Why would logs from 100% user-space code like ExternalMethod and StaticPingPong be attributed to the kernel process? I think the term user-space is deeply misleading when it comes to DriverKit. While it’s true in the basic technical sense, it is DEEPLY misleading when it comes to the practical relationship a DEXT has with the rest of the system. Practically speaking, your DEXT has very little connection to the larger system. It talks the kernel through the underlying DEXT infrastructure and it talks to user space through IOUserClient. That's ALL that exists, so the direct answer is that it's logging through the kernel because that's the only way it can log. WHY it works

entity is a selector on NSManagedObject and you have smashed it with a relationship to one of your entities. That's not a valid managed object model (none of your PersistentModel classes can have a property named entity).

Yeah, that is what I mentioned above, and it's because a too-many relationship is expressed as a set (NSSet) in Core Data, which is used by SwiftData default store. I don't think the behavior is formally documented. If you don't mind, please file a feedback report. Best, —— Ziqiao Chen  Worldwide Developer Relations.

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?