CoreData Relationship ich habe mich verrant

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

    • CoreData Relationship ich habe mich verrant

      Hi,

      irgendwie blicke ich es nicht mehr, obwohl ich es schon Tausend mal gemacht habe.
      Ich habe 2 Entitäten:
      Kunde
      Projektanschrift

      In Kunde sind Anschrift etc.
      In Projektanschrift sind die Adresse des eigentlichen Lieferorts und Projekt relevante Daten.

      Es existiert eine 1:to many Relationship von Kunde zu Projektanschrift.
      Ich lege mir einen Kunden an, kein Problem. Die Kunden gebe ich mir in eine Tabelle aus. Sehr gut.

      Nun lege ich mir eine projektanschrift an. Auch kein Problem.

      Aber mit kunde.projektanschrift = neueProjektanschrift erhalte ich nur die Meldung "Incompatible pointer types assigning to NSSet _strong

      Äh, ???

      'einen Tipp für mich, ich steh gerade total auf dem Schlauch
      Karin
    • Zwei Möglichkeiten:
      Set aus den alten Anschriften + die neue Anschrift an n-Beziehung übergeben.

      C-Quellcode

      1. kunde.projektanschrift = [NSSet setWithObject:neueProjektanschrift];


      Statt der n die 1er Beziehung reinwerfen.

      C-Quellcode

      1. neueProjektanschrift.kunde = kunde;
      «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
    • LUcas ich muss dann doch mal den Spendenbutton aktivieren.

      Klar doch, war die ganze Zeit mit 1:1-Beziehungen unterwegs und mit Deinem Posting viel es wie Bläter von den Gänseblümchen.

      Ich merke mir: Jeden Tag einmal eine 1:1 und eine 1:to many anlegen, bis es sitzt.

      Ich dachte schon, ich wäre komplett neben der Spur

      Liebe Grüße
      Karin
    • Ich habe mir für so etwas angewöhnt, für meine Core Data Objekte Klassen von NSManagedObject abzuleiten.
      Da kümmere ich mich dann einmal um die ganzen Relations-Dinger, in dem ich für jede ein addRelation: und removeRelation: einbaue.

      In meinem Code kann ich dann auch Wochen später noch sagen: [kunde addAnschrift:neueAnschrift]; ohne das irgendwas daneben geht und ich mich mit Exceptions herumschlagen muss. :)
      «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
    • alexlaske schrieb:

      Und am Besten schreibst du deinen eigenen Code in eine Kategorie zur NSManagedObject-Subclass. Dann musst du den nicht jedes Mal mühsam kopieren, wenn du was an deiner Entität änderst und dir von Xcode die Klasse neu erzeugen lässt..

      Gruß Alex

      alexlaske schrieb:

      Und am Besten schreibst du deinen eigenen Code in eine Kategorie zur NSManagedObject-Subclass. Dann musst du den nicht jedes Mal mühsam kopieren, wenn du was an deiner Entität änderst und dir von Xcode die Klasse neu erzeugen lässt..

      Gruß Alex

      alexlaske schrieb:

      Und am Besten schreibst du deinen eigenen Code in eine Kategorie zur NSManagedObject-Subclass. Dann musst du den nicht jedes Mal mühsam kopieren, wenn du was an deiner Entität änderst und dir von Xcode die Klasse neu erzeugen lässt..

      Gruß Alex

      Geht auch mit Beiträgen. :-] Ja, ja, ich weiß, der Server hatte gerade Schluckauf.

      MOGenerator macht ja so etwas, weshalb einige darauf schwören. Ich verstehe den Grund nicht: -mutableSetValueForKey:
      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"?
    • Lucas de Vil schrieb:


      Set aus den alten Anschriften + die neue Anschrift an n-Beziehung übergeben.

      C-Quellcode

      1. kunde.projektanschrift = [NSSet setWithObject:neueProjektanschrift];


      [[kunde mutableSetValueForKey:@"projektAnschriften"] addObject:neueProjektAnschrift]
      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"?
    • alexlaske schrieb:

      @Amin: wenn es nur darum geht, ist ne Kategorie sicher Overkill. Wenn aber noch Readonly-Properties und andere Sachen dazu kommen, dann hat es sich bei mir schon mehrfach bewährt.. Sorry wegen des Schluckaufs.. ;-)

      Also, eine Kategorie würde ich sicherlich niemals nehmen. Diese Empfehlung stammt von "Mail-Verteilergrößen" aus Zeiten, als Apple einfach noch alles in eine Kategorie stopfte, weil gerade nichts Besseres einfiel. Da war ja ein Textfeld ein Window-Delegate. "Und wenn ich mal nicht weiter weiß, dann baue ich mir ne Kategorie von NSObject."

      Man kann an eine Subklasse denken. Aber neben Bequemlichkeit fällt dafür eigentlich kein Grund sein.
      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 klar bin ich bequem! Wenn ich eine recht komplizierte Subklasse von NSManagedObject habe und etwas ändere, dann habe ich natürlich keine Lust, meine Subklasse komplett händisch dem Model anzupassen. Da lasse ich mir doch lieber die Klasse neu erzeugen und sage einmal "Import Kategorie" und alles andere bleibt bestehen.. Aber das kann ja jeder machen, wie er will und meint. Ich denke, das ist in diesem Fall reine Geschmackssache..
    • alexlaske schrieb:

      Na klar bin ich bequem! Wenn ich eine recht komplizierte Subklasse von NSManagedObject habe und etwas ändere, dann habe ich natürlich keine Lust, meine Subklasse komplett händisch dem Model anzupassen. Da lasse ich mir doch lieber die Klasse neu erzeugen und sage einmal "Import Kategorie" und alles andere bleibt bestehen...

      Macht den Code für Andere sicherlich unglaublich lesbar...
      «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
    • Lucas de Vil schrieb:

      alexlaske schrieb:

      Na klar bin ich bequem! Wenn ich eine recht komplizierte Subklasse von NSManagedObject habe und etwas ändere, dann habe ich natürlich keine Lust, meine Subklasse komplett händisch dem Model anzupassen. Da lasse ich mir doch lieber die Klasse neu erzeugen und sage einmal "Import Kategorie" und alles andere bleibt bestehen...

      Macht den Code für Andere sicherlich unglaublich lesbar...

      Ich verstehe ja schon nicht, wie eine Subklasse von NSManagedObject kompliziert werden kann. Das ist immerhin eine Modelklasse. Aber er hat mich auch nicht richtig verstanden: Die Bequemlichkeit, die ich meinte, bezieht sich ja gerade auf die Subklasse.

      Ich denke, dass das aber ohne konkretes Beispiel, was er meint, ohnehin eine sinnlose Diskussion wird.

      Ich bin ein großer Freund von Kategorien. Aber ich verwende Kategorien nicht, um in einer Basisklasse Funktionalität vorzugaukeln, die nur bestimmte Subklassen beherrschen.
      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"?