OSX Core Data Entity PrimaryKey?

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

Aufgrund der Corona-Krise: Die Veröffentlichung von Stellenangeboten und -gesuchen ist bis 31.12.2020 kostenfrei. Das beinhaltet auch Angebote und Gesuche von und für Freischaffende und Selbstständige.

  • OSX Core Data Entity PrimaryKey?

    Hallo,

    Core Data legt doch automatisch für jede Entity einen PrimaryKey an. Zumindest wird dies innerhalb der Debug-Informationen angezeigt.

    Debug-Auszug: CoreData: sql: SELECT 0, t0.Z_PK, t0.Z_OPT, t0.ZUSERDBIRTHDAY, ...

    Nachdem via NSFetchRequest() die Daten aus der Entity ausgelesen wurden, finde ich aber keinen Hinweis auf den PrimaryKey Z_PK.


    Quellcode

    1. let context = appDelegate.persistentContainer.viewContext
    2. let request = NSFetchRequest<NSFetchRequestResult>(entityName: "Personen")
    3. let results = try context.fetch(request)
    4. for item in results {
    5. if let result = item as? NSManagedObject {
    6. print("PrimaryKey: ", result.value(forKey: "Z_PK") as Any)
    7. }
    8. }

    Obiger Code führt zu nachfolgender Fehlermeldung: ... the entity Users is not key value coding-compliant for the key "Z_PK".

    Folglich muss der Key-Name anders lauten. Kann mir jemand mitteilen wie der Key-Name lautet oder wie ich sonst den Wert des PrimaryKeys auslesen kann?


    Vielen Dank.
  • MCDan schrieb:

    Auf interne Variablen eines NSManagedObject solltest Du nicht zugreifen!

    Wenn sich die interne Verarbeitung von CoreData ändert, dann funktioniert Deine App nicht mehr und stürzt ggf. sogar ab.

    Wenn Du für die App einen Primary Key bei einer Entity benötigst, dann solltest Du diesen zum Datenmodel der Entity hinzufügen.
    @MCDan: Dachte mir schon so etwas. Wäre so einfach gewesen. Das Datenmodel darf ich leider nicht ändern. Naja, nun erst einmal Cafépause und hoffen, dass mir da eine simple Lösung einfällt. Danke
  • Im Ausgangs-ViewController wird der Inhalt - also die Daten - eines NSManagedObject, nicht das NSManagedObject selbst, an einen zweiten ViewController übergeben. Der zweite ViewController diente ursprünglich nur dazu einen Teil des Datensatzes anzuzeigen. Nun wurde das Layout überarbeitet, nicht aber das Datenmodell. ?( Ist etwas ungeschickt, lässt sich aber ohne größeren Aufwand nun nicht beheben, zumindest nicht wenn das Budget eingehalten werden soll. :rolleyes:

    Wenn ich nun genau diesen Datensatz vom 2'tnVC aus löschen bzw. speichern möchte, müsste ich nun die Daten mit dem Array result abgleichen bzw. vergleichen um zum Ursprungsobject vom Typ NSMangedObject zu gelangen. Da aber der Anwender die Möglichkeit hat die Daten zu verändern, bevor er den Button Löschen bzw. Speichern betätigt, müsste ich nun von allen übertragenen Variablen - Kopien, für den Abgleich, vorhalten. :S

    Wenn Du einen simplen Lösungsansatz (welcher mit wenig Änderungen verbunden ist) parat hättest, würdest Du mir sehr helfen.
  • OSXDev schrieb:

    Wenn Du einen simplen Lösungsansatz (welcher mit wenig Änderungen verbunden ist) parat hättest, würdest Du mir sehr helfen.
    Kannst Du vielleicht - beispielsweise bei der Übergabe zum 2. VC - einen Hash der ursprünglichen Attribute erstellen und mitgeben? Der 1. VC könnte dann eine Methode haben, um das zum Hash passende NSManagedObject zu ermitteln (z. B. über ein parallel zu result gepflegtes Array), auch wenn sich die Attribute mittlerweile geändert haben.

    Nur so als Lösungsansatz, Mattes

    P.S.: Oder übergib die o. g. objectID als zusätzlichen Parameter / Property des 2. VC...
    Diese Seite bleibt aus technischen Gründen unbedruckt.
  • OSXDev schrieb:

    @Mattes: Der Hinweis einem Hash zum Vergleich heranzuziehen hört sich gut an. :) Ist nicht sehr aufwendig und schnell umzusetzen. Danke
    Gerne! Allerdings stellt sich mir die Frage, warum dann nicht direkt besagte objectID verwenden? Die ist im Zweifel sogar als URI persistierbar und Du hast direkt Methoden des NSManagedContext, das entsprechende NSManagedObject zu bekommen ... unabhängig vom NSFetchedResultsController.

    Vielleicht nochmal überdenken, Mattes
    Diese Seite bleibt aus technischen Gründen unbedruckt.
  • MyMattes schrieb:

    OSXDev schrieb:

    @Mattes: Der Hinweis einem Hash zum Vergleich heranzuziehen hört sich gut an. :) Ist nicht sehr aufwendig und schnell umzusetzen. Danke
    Gerne! Allerdings stellt sich mir die Frage, warum dann nicht direkt besagte objectID verwenden? Die ist im Zweifel sogar als URI persistierbar und Du hast direkt Methoden des NSManagedContext, das entsprechende NSManagedObject zu bekommen ... unabhängig vom NSFetchedResultsController.
    Vielleicht nochmal überdenken, Mattes
    Habe ich ebenfalls testweise umgesetzt und dieser Ansatz ist für zukünftig anstehende Erweiterungen bestimmt der besser Ausgangspunkt. :thumbsup:
  • MCDan schrieb:

    Mir ist auch nicht ganz klar, warum Du das ManagedObject nicht über die objectID löschst. Genau dazu ist diese da, um ein ManagedObject eindeutig zu identifizieren.

    Noch einfacher wäre es natürlich das ManagedObject an den 2. ViewController zu übergeben, wenn man dieses dort auch löschen kann.
    Stimme Dir zu, aber dies entscheide ich hier nicht. Muss hier verschiedene Ansätze präsentieren und dann geht dies in diesem Fall direkt in die nächsten Hände. Würde gerne auch das zugrunde liegen Datenmodell vollständig überarbeiten, aber .....

    @manoh, @MCDan, @MyMattes: Euch allen ein Dankeschön für Eure Anregungen. :thumbsup: