Core Data, Drag&Drop und Reference Counting

  • Ähm, die Geschichte mit copyWithZone habe ich rausgenommen.. Das wurde ja vorher schon kritisiert. Wo siehst Du das denn?

    Mit dem Absturz kann ich mir eigentlich nur erklären, wenn kein vierstelliges Jahr eingegeben wird (da müsste ich dann (in der Final-Version) wohl mal ne Validation einfügen). Da hast Du recht. Mir ging es jetzt erstmal darum, ob die MO-Subklassen usw. erstmal einigermaßen aussehen..

    Edit: Absturz lag vermutlich an o.g. Ursache. Da daraus per substringFromIndex später IDs erstellt werden, ging es natürlich nicht, wenn das Jahr nicht genau so eingegeben wurde, wie ich mir das vorgestellt habe. Hab da nun was gebastelt, das ggf. Platzhalter einfügt, wenn das Jahr zu kurz ist..

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von alexlaske ()

  • Darf ich fragen, wofür du die IDs brauchst?
    Falls ja: wofür brauchst du die IDs?

    Nach dem Anlegen von Schülern tauchen diese übrigens bei mir nicht in der Ansicht auf, Klausuren mögen sich gar nicht anlegen lassen.
    Bist du bei den beiden Punkten noch nicht so weit vorangeschritten?
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P

  • Genau, Schüler und Klausuren anlegen ist noch nicht drin. Da weiß ich noch nicht genau, wie ich das mache. Bzw. kann man Schüler anlegen, diese werden aber noch nicht angezeigt. Idee ist, dass später im rechten Teil je nach Auswahl die Schüler oder die Klausuren für das links ausgewählte Fach erscheinen. So weit bin ich aber noch nicht. Ich will jetzt erstmal die CD-Geschichte in Ordnung haben, bevor ich neue Sachen einbaue, die ich dann sonst evtl. später wieder komplett ändern muss..

    Die IDs will ich später evtl. für FetchRequests nutzen. Das ist aber auch noch nicht sicher. Ich muss ja nachher meinen Array-Controller für das (noch zu erstellende bzw. anzubindende) TableView auf der rechten Seite befüllen. Und dafür muss ich mir ja alle Schüler, die in einem Fach oder einer Klasse sind, holen. Ich bin da übrigens gerade bei outlineViewSelectionIsChanging im ALMainWindowWC am Probieren, wie ich mir die entsprechenden Student-Entitäten holen kann (klappt aber auch noch nicht). Und da weiß ich eben nicht genau, ob der Fetch Request direkt nach Entitäten ( also: predicateWithFormat: @"ALL membersOfSubject == %@", item ) oder eben nach den IDs ( predicateWithFormat: @"ALL membersOfSubject.subjectID == %@", [item subjectID] ) suchen soll. Daher habe ich mir das gebastelt. Außerdem werde ich sie wahrscheinlich später für die Zuordnung der Klausuren brauchen.

  • Ah, copyWithZone: ist draußen. War ne alte Fassung. Aber du hast ja immer noch jede Menge Kopiererei drin. Wieso? Was kopierst du da?

    Du brauchst auch keinen Fetch-Request und keine IDs. Das ist keine Datenbank.

    Ich sehe überhaupt nicht, warum du überhaupt eine Subklasse von NSManagedObject benötigst. Was hat dich dazu veranlasst?
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • Na ja, die Kopiererei habe ich fürs Drag and Drop drin. Wenn ich da was kopiere, muss ich das ja irgendwie machen. Und da steht ja, dass man per insertNewObject... ein neues Objekt erstellen und das dann "befüllen" soll. Und das mache ich mit den Copy-Methoden in den MO-Subklassen, damit mein WC nicht so riesig groß wird.

    OK, das mit den IDs muss ich nochmal überdenken.

    Was meinst Du mit, ich brauche keine Fetch Requests? Wenn ich alle Student-Entitäten haben will, die einem Subject oder einer Klasse angehören, muss ich das doch irgendwie rausfinden, oder? Wie mache ich das denn dann?

    Die Subklassen habe ich angelegt um z.B. die zusätzlichen Methoden einzubauen oder eben für die computed Properties. Klar, wenn ich die IDs abschaffen sollte, dann kann ich mir die Subklassen evtl. sparen..

  • Markus Müller schrieb:

    Die IDs brauchst Du eigentlich auch nicht:NSManagedObject -objectID
    URIRepresentation(NSMangedObjecID)
    Mit dieser URI arbeitet man für gewöhnlich beim Drag and Drop, wenn man CD benutzt.

    Wie Du an Deine to-many-relationships kommst, hat Dir Amin ja schon geschrieben. Immer schön geradeaus denken - Cocoa nimmt Dir sehr viel beschwerliche Arbeit ab.

    Ich benutze ja beim D&D die URI Representation, wie es im CD Programming Guide und im Buch von Amin beschrieben ist. Wenn ich Move mache, ist das ja eindeutig. Wenn ich ein Subject in eine andere Class schiebe, setze ich einfach die Relationship neu. Wenn ich aber ein Copy mache, muss ich doch erstmal ein neues Objekt erzeugen, oder wie mache ich das? Ich hatte mir nun überlegt und es ja so auch gemacht, dass ich ein neues Subject-Objekt erzeuge und dann aus dem kopierten Objekt die Attribute setze bzw. die Relationships ggf. anpasse. Was ist daran nicht richtig?!?

    So wird es in der Documentation ja auch beschrieben. Und zwar indem man die Methoden keysToBeCopied und dictionaryRepresentation erstellt und damit dann das neue Objekt befüllt..