DatabaseTrigger: Beim speichern eines Datensatzes eine eigene Nummer vergeben
Hallo und Herzlich Willkommen zu unserem dreizehnten Teil der Serie HowToDoIt!
Inhalt dieser Folge
Beim speichern eines Datensatzes wollen wir eine eigene Nummer vergeben, damit anhand dieser Nummer die Datensätze sortiert werden können.
Video
The Author
6 Comments
Hallo Frank,
vielen Dank für die großartigen Videos. Ich bin begeistert. Weiter so!!
Eine kleine Frage habe ich dennoch zu deinem heutigen Teil:
Würde es nicht reichen, die Order-Nummer (analog zum Namen des Jobs) in der createJobWithName()-Methode zu setzen? Hat die willSave()-Methode hier Vorteile, die ich übersehen habe, oder nutzt du sie nur, um sie uns vorzustellen?
Viele Grüße,
Daniel
Hi Daniel,
und Du hast so etwas von Recht 🙂
Die Korrektur kommt gleich mit dem heutigen Video!
Übrigens benutzt der „Advanced Core Data Anwender“ für Aktionen bei Erstellung von Entitäten die dafür vorgesehene Methode „ awakeFromInsert“. Da braucht man dann auch keine solche Krücken, äh Pattern. 🙂
Hi Michael,
das ist ein guter Punkt, es ärgert mich jedoch, wenn Du mir vorwirfst, ich würde Euch “Krücken” zeigen. Denn ich mache vieles aus gutem Grund.
Meine vorherige Antwort habe ich noch einmal überdacht und etwas weicher formuliert, denn hier im SwiftBlog sind wir unter Freunden und gehen an die Sache mit Spaß heran 🙂
Michael, schau doch bitte einmal, was Apple zu awakeFromInsert sagt:
“You are typically discouraged from performing fetches within an implementation of awakeFromInsert. Although it is allowed, execution of the fetch request can trigger the sending of internal Core Data notifications which may have unwanted side-effects.”
Das heisst, man darf im awakeFromInsert keinen Fetch machen, um beispielsweise die größte oder kleinste vergebene Nummer zu finden. Es dürfen nur Werte gesetzt werden, die aus anderen Quellen berechnet oder geladen werden. Ein Zugriff auf die eigene Core Data Persistenzschicht ist zu vermeiden, wenn man nicht will, dass die referenzielle Integrität wegen Seiteneffekten zerstört wird.
Mir ist das vor Jahren tatsächlich passiert und ich habe den Fehler erst nach vielen Stunden gefunden und teuer dafür bezahlt.
Nur aus diesem Grund zeige ich Euch hier “die Krücke”, denn die ist frei von Seiteneffekten. Die Eleganz vermisse bei meiner Lösung auch, allerdings lässt Core Data da keinen Raum für schönere Lösungen.
Mein guter Rat an alle “Advanced Core Data Anwender”: Bitte auch Apples Dokumentation lesen, dann werdet Ihr zum “Advanced Core Data Programmierer” 🙂
So, und jetzt gehe ich los und kaufe mir gleich noch eine Krücke, denn ich weiß, dass noch 53 Videos darauf warten veröffentlicht zu werden…
Herzliche Grüße
Franky
Hallo Frank,
nicht ärgern, ich habe doch extra noch einen Smiley angehängt.
Mein Hinweis auf die Methode „awakeFromInsert“ soll nur darauf aufmerksam machen, dass es in Core Data einen definierten Punkt für Aktionen bei Erstellung von Entitäten gibt. Da es in diesem Video ja um die Erstellung von Entitäten geht, fand ich das erwähnenswert.
Das mit dem Fetch ist natürlich ein valider Punkt. Allerdings ist der nicht verboten (steht sogar in deinem Zitat ;)), sondern es wird davon abgeraten, weil es zu Seiteneffekten kommen kann.
Trotzdem ist das hier vorgestellte Pattern unnötig, denn wenn wir schon beim Dokumentation lesen sind, schauen wir doch mal, was Apple zu willSave sagt:
„If you change property values using primitive accessors, you avoid the possibility of infinite recursion, but Core Data will not notice the change you make.“
Also, nicht ärgern, weiter machen. Ich werde zukünftig auch bei meiner Wortwahl vorsichtiger sein, denn geschrieben kommt manches ja leider nicht so an, wie gesprochen.
Viele Grüße
Michael
Hi Michael,
Zu willSave:
“If you change property values using primitive accessors, you avoid the possibility of infinite recursion, but Core Data will not notice the change you make.”
primitive accessors, wie beispielsweise willAccessValueForKey, willChangeValueForKey, didChangeValueForKey, u.s.w. habe ich genau aus diesem Grund auch nicht verwendet, denn ich möchte ja, dass meine Änderungen gespeichert werden. Allerdings habe ich dann mit der Rekursion zu kämpfen und genau dafür habe ich hier eine Lösung vorgestellt, die in Deinen Augen eine Krücke ist.
Wenn Du eine andere Lösung hast, die die Daten speichert, nicht in die Rekursion-Falle läuft und nicht awakeFromInsert verwendet, weil dort nicht gefetched werden darf, bin ich Dir sehr dankbar, wenn Du diese in einem Video zusammen fasst und mir und den anderen Swift-Blog-Lesern zur Verfügung stellst.
Ich kann und will an so vielen Stellen noch so viel von anderen Experten lernen und freue mich immer, wenn der Schlag der Erkenntnis mich trifft und ich mich frage, warum ich dieses oder jenes immer dermassen falsch angegangen bin.
Mir hat iOS niemand erklärt, CoreData-Bücher die wirklich Klarheit schaffen habe ich noch keines gefunden und so habe ich mich über Stunden, Tage und Wochen damit beschäftigt Lösungen zu finden die stabil funktionieren.
Sehr gerne möchte ich diese Krücken jedoch wegwerfen und wieder befreit durch den Code Joggen. Hilf mir doch bitte dabei 🙂
liebe Grüße
Franky