Merkwürdige Warnung im CoreData Model

    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.

    • Core Data benötigt die Angabe der Rückbeziehung, damit es weiß, wie es dir relationalen Tabellen aufzubauen hat. Dies erfolgt im Wesentlichen "umgekehrt" zur Denke in OOP und hängt aber von beiden Richtungen ab. Ich kann das bei Interesse noch ausführen, letztlich ist es für dich aber gleichgültig.

      Es gibt keine Probleme, allenfalls verringert sich die Performance.
      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"?
    • Gerade da habe ich aber das Verständnisproblem - ich arbeite beruflich mit EclipseLink, und bei solch einem Beispiel, wo Adresse auch noch von bspw. Restaurant, Autohaus, Tankstelle aggregiert werden kann, sollte doch klar sein, dass man die Fremdschlüsselspalte in die Tabellen der 1:1-aggregierenden Objekte verlegt. Dazu braucht man keine Rückbeziehungen. Und bei 1:n-Beziehungen, wo auch gemoppert wird, ist es noch klarer.
    • WernerB schrieb:

      Gerade da habe ich aber das Verständnisproblem - ich arbeite beruflich mit EclipseLink, und bei solch einem Beispiel, wo Adresse auch noch von bspw. Restaurant, Autohaus, Tankstelle aggregiert werden kann, sollte doch klar sein, dass man die Fremdschlüsselspalte in die Tabellen der 1:1-aggregierenden Objekte verlegt. Dazu braucht man keine Rückbeziehungen. Und bei 1:n-Beziehungen, wo auch gemoppert wird, ist es noch klarer.
      Vom Standpunkt der OOP aus gibt es keine 1-zu-1- und keine 1-zu-N- und keine N-zu-M-Beziehung. Es gibt nur eine zu-N- oder zu-1- Beziehung. In der Definition einer Klasse Person habe ich möglicherweise einen direkten Verweis auf Instanzen der Klasse Addess. Möglicherweise einen einfachen, möglicherweisen einen über eine Collection. Wie die Rückbeziehung ist, erkenne ich in der Klassendefinition nicht und sol ich auch gar nicht erkennen.

      Quellcode

      1. @interface Person : NSObject // Nix Core Data
      2. @property Address *mainAdress;
      3. @proeprty NSSet *adresses;
      4. @end

      Hast du jemals der Klassendefinition eine Information hinzugefügt, wie es sich mit der Rückbeziehung verhält, also ob eine Adresseninstanz zu mehreren Personen gehören kann? Diese Frage stellt man sich nicht in der Klassendefinition.

      Wenn OOP also nur eine Richtung betrachtet, man aber für die Modellierung in SQL zwei Richtungen benötigt, muss das jetzt jemand angeben.

      Bei einer 1-zu-N-Beziehung ist das noch klarer. Hier würde man in der Zieltabelle eine Fremdschlüsselspalte einfügen. Klar, doch. Vor allem dann, wenn es eine 1-zu-M-Rückbeziehung gibt. Klar.
      Oder doch nicht? Würde man nicht vielleicht eine weitere Tabelle einfügen, weil es jetzt eine N-zu-M-Beziehung ist? Ich modelliere meine relationalen Datenbanken so.

      Core Data sagt auch nicht, dass es das Modell nicht modellieren kann. Dann würdest du ja keine nachvollziehbare Warning, sondern einen merkwürdigen Error bekommen. Es teilt dir damit lediglich mit, dass bei Angabe nur einer Beziehung es möglicherweise einen ungewöhnlichen Store erzeugt. Ganz unabhängig vom konkretem Fall.
      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"?
    • WernerB schrieb:

      Aber ein Persistenzframework, das hier mit SQLite arbeitet.
      Aha und woher weiß der Model-Editor, für was einen Zielstoretypen er verwendet wird? Und wenn er das wüsste, wie kann ich dann das Modell gleichzeitig für einen SQL-Store und einen In-Memory-Store verwenden?

      WernerB schrieb:

      Schau Dir mal die Doku zu EOF an.
      Falls man einen Object-Relational-Mapper (ORM) schreibt, gehst man da vielleicht naiv heran: Objekte sind Zeilen, Referenzen sind Fremdschlüssel. Ist ja alles gleich. Kann man alles so schön 1:1 übersetzen.

      Wenn man dann allerdings anfängt, verliert man seine Naivität. Man kommt sozusagen in die ORM-Pubertät und stellt fest, dass es von scheinbar gleichen Dingen bei OOP und rDMBS verschiedene Ansichten gibt, zum Beispiel die Beziehungen. (Es gibt noch andere, zum Beispiel Subklassen.) Das bezeichnet man als Object-Relational-Impedance-Mismatch. Und jedesmal, wenn du an eine solche Stelle kommst, musst dich fragen; Mache ich das jetzt OOPish oder mache ich das SQLish?

      Jedes ORM-Framework kann diese Frage anders beantworten. Es ist dann nicht nur so wie sonst, dass "ich kenne das doch aus dem Framework X, schaue dir das mal an" an sich ein schlechter Ansatz ist. Es ist in diesem Falle ein falscher Ansatz. Vergiss, was du aus anderen ORM-Frameworks kennst. Vodka gibt es an der Forumstheke. Das hilft. (Das verhält sich so wie bei untreuen Ex-Freundinnen, bei denen Alkohol auch allgemein als probates Mittel zum Vergessen angesehen wird. So gesehen ist also EOF eine verdammte Schlampe, die dich ohnehin nicht verdient hat.)
      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"?
    • Ich arbeite beruflich nun seit 2000 mit TOPLink/EclipseLink, und schätze halt die umfangreichen Mapping-Möglichkeiten, die weit über EOF hinausgehen. Insofern möge man meine Verwöhntheit entschuldigen. Mir sind die Warnings auch egal, so lange mir das Zeug nicht zur Runtime um die Ohren fliegt.
      Der SQLite-IncrementalStore umfasst ja dann wohl eine mit den CoreData-AtomicStore-Stereotypen verklebte EOF-Umgebung, und ich bin nicht der einzige, der darauf wartet, dass Apple die Schnittstelle weiter öffnet als mit NSIncrementalStore. Obwohl letzteres locker die Möglichkeit böte, eine zu der EclipseLink-Foundation, nicht JPA, analoge ORM-Schnittstelle zu bauen. Ich empfehle wirklich mal, sich die Version 2.4.2 von EclipseLink herunterzuladen, die letzte, die noch die Mapping-Workbench hatte.
    • WernerB schrieb:

      Ich arbeite beruflich nun seit 2000 mit TOPLink/EclipseLink, und schätze halt die umfangreichen Mapping-Möglichkeiten, die weit über EOF hinausgehen. Insofern möge man meine Verwöhntheit entschuldigen. Mir sind die Warnings auch egal, so lange mir das Zeug nicht zur Runtime um die Ohren fliegt.
      Der SQLite-IncrementalStore umfasst ja dann wohl eine mit den CoreData-AtomicStore-Stereotypen verklebte EOF-Umgebung, und ich bin nicht der einzige, der darauf wartet, dass Apple die Schnittstelle weiter öffnet als mit NSIncrementalStore. Obwohl letzteres locker die Möglichkeit böte, eine zu der EclipseLink-Foundation, nicht JPA, analoge ORM-Schnittstelle zu bauen. Ich empfehle wirklich mal, sich die Version 2.4.2 von EclipseLink herunterzuladen, die letzte, die noch die Mapping-Workbench hatte.
      Das finde ich super!
      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"?
    • macmoonshine schrieb:

      Amin Negm-Awad schrieb:

      So gesehen ist also EOF eine verdammte Schlampe, die dich ohnehin nicht verdient hat.
      ... aber ich habe sie doch wirklich geliebt. ;( ;( ;(
      Dein dreckigen Phantasien sind keine Liebe. (Hat sie mir jedenfalls gesagt.)
      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"?