Das deutsche Python-Forum

Hallo Community,

ich habe ein Problem bezüglich der ForeignKey-Beziehung von Django.

Momentane models.py einer App:

from django.db import models

# Create your models here.

class Artikel(models.Model):
    title = models.CharField(verbose_name="Titel",max_length=200)
    pub_date = models.DateTimeField('Datum')
    tags = models.CharField(verbose_name="Tags",max_length=1000)

    text = models.TextField(verbose_name="Text")

    def __unicode__(self):
        return self.title

    class Meta:
        verbose_name_plural = "Artikel"


class Podcast(models.Model):
    artikel = models.ForeignKey(Artikel)
    title = models.CharField(verbose_name="Titel",max_length=200)
    pub_date = models.DateTimeField('Datum')
    tags = models.CharField(verbose_name="Tags",max_length=1000)

    link = models.CharField(verbose_name="URL",max_length=300)
    desc = models.TextField("Beschreibung")    

    def __unicode__(self):
        return self.title

    class Meta:
        verbose_name_plural = "Podcasts"

Normalerweise ist ja jetzt ein Bezug auf die vorherige Klasse gestellt. Nun stellt sich mir die Frage, wie es denn jetzt richtig ist. Ich kriege einen Datenbank-Fehler.

Code: Alles auswählen

no such column: artikel_artikel.podcast_id

Die Anweisung dazu steht aber in den SQL-Informationen die ich über

Code: Alles auswählen

~$ python manage.py sql artikel

bekomme.

Code: Alles auswählen

BEGIN;
CREATE TABLE "artikel_artikel" (
    "id" integer NOT NULL PRIMARY KEY,
    "title" varchar(200) NOT NULL,
    "pub_date" datetime NOT NULL,
    "tags" varchar(1000) NOT NULL,
    "text" text NOT NULL
)
;
CREATE TABLE "artikel_podcast" (
    "id" integer NOT NULL PRIMARY KEY,
    "artikel_id" integer NOT NULL REFERENCES "artikel_artikel" ("id"),
    "title" varchar(200) NOT NULL,
    "pub_date" datetime NOT NULL,
    "tags" varchar(1000) NOT NULL,
    "link" varchar(300) NOT NULL,
    "desc" text NOT NULL
)
;
COMMIT;

Was mache ich falsch?

Danke im Vorraus,

Maik

In dem SQL hat der podcast einen Referenz auf den Artikel (artikel_id). Dein Modell will aber genau andersherum referenzieren. Das kann dann ja nicht gutgehen... wie hast du denn die Tabellen erzeugt? Von Hand? Oder mit einer aelteren Modellierung?

Hallo deets,

ich hatte mal ausprobiert dass podcast auf Artikel referenziert. Hat auch nicht geklappt und ich habe es zurückgestellt. Anscheinend funktioniert der Befehl syncdb nicht mehr.

Danke

Maik

ich kenne django nicht wirklich, aber wieso kannst du die DB nicht einfach wegschmeissen & neu generieren? Offensichtlich stimmt das Schema mit dem Modell nicht ueberein. Ob's da nun Magie von Django gibt oder nicht ist doch eigal - neu machen kannst du sie immer, oder wenn's sein muss von Hand umaendern.

Die Lösung des Problems:

Ich hatte beiden Models die gleichen Feldnamen zugewiesen, dies hat sich aber nicht vertragen. Also musste ich die Felder einfach umbenennen und jetzt funktioniert es.

Was lernt man daraus:

Gebe einem Model immer einzigartige Namen.

"Your model variables must be unique"

Maik

daemonTutorials hat geschrieben:Ich hatte beiden Models die gleichen Feldnamen zugewiesen, dies hat sich aber nicht vertragen. Also musste ich die Felder einfach umbenennen und jetzt funktioniert es.

Was lernt man daraus:
Gebe einem Model immer einzigartige Namen.

Da deine Behauptung mit den nicht zulässigen identischen Feldnamen falsch ist lernen wir etwas anderes daraus:
Verstehe das Problem bevor du dich an die Lösung machst.

/me hat geschrieben:
daemonTutorials hat geschrieben:Ich hatte beiden Models die gleichen Feldnamen zugewiesen, dies hat sich aber nicht vertragen. Also musste ich die Felder einfach umbenennen und jetzt funktioniert es.

Was lernt man daraus:
Gebe einem Model immer einzigartige Namen.
Da deine Behauptung mit den nicht zulässigen identischen Feldnamen falsch ist lernen wir etwas anderes daraus:
Verstehe das Problem bevor du dich an die Lösung machst.

Kurze Frage: Was soll denn das Problem sein, wenn das ändern der Variablen der Fehler war? Nachdem ich die DB umbenannt habe und die Feldnamen neu vergeben habe und die DB neu angelegt habe hat alles funktioniert.

Wo liegt denn der Fehler?

Maik

daemonTutorials hat geschrieben:Kurze Frage: Was soll denn das Problem sein, wenn das ändern der Variablen der Fehler war? Nachdem ich die DB umbenannt habe und die Feldnamen neu vergeben habe und die DB neu angelegt habe hat alles funktioniert.

Der genaue Fehler lässt sich jetzt natürlich nicht mehr wirklich ermitteln, aber ich bin mir bei meiner Einschätzung trotzdem recht sicher.

Das Datenmodell sah ursprünglich etwas anders aus und wurde mit syncdb in die Datenbank geschrieben. Dann wurden Änderungen am Datenmodell vorgenommen und erneut ein syncdb durchgeführt. Das führt zu einem inkonsistenten Zustand. syncdb baut die Datenbank nach Modelländerungen nicht komplett neu auf. Es ist deine Aufgabe als Entwickler, die Strukturänderungen dann in der Datenbank händisch durchzuführen - oder south einzusetzen.

Jetzt hast du die komplette Datenbank entfernt und neu aufbauen lassen. Damit hast du dann natürlich einen konsistenten Zustand erhalten und zwar unabhängig davon ob in zwei Tabellen der gleiche Spaltenname verwendet wird oder nicht.

Danke /me,

das war sehr aufschlussreich.

Dass syncdb die Daten inkonsistent macht ist nicht gerade toll.

Ich habe jetzt south installiert und es arbeitet toll.

Ich danke dir!

daemonTutorials hat geschrieben:Dass syncdb die Daten inkonsistent macht ist nicht gerade toll.

Ehe jemand einen falschen Eindruck bekommt: Die Daten in der Datenbank bleiben natürlich konsistent. Änderungen an bestehenden Models werden allerdings nicht in die Datenbank nachgezogen und führen damit zu einer inkonsistenten Struktur bezüglich Model und Datenbank.

/me hat geschrieben:
daemonTutorials hat geschrieben:Dass syncdb die Daten inkonsistent macht ist nicht gerade toll.
Ehe jemand einen falschen Eindruck bekommt: Die Daten in der Datenbank bleiben natürlich konsistent. Änderungen an bestehenden Models werden allerdings nicht in die Datenbank nachgezogen und führen damit zu einer inkonsistenten Struktur bezüglich Model und Datenbank.

Also wurde Django so entwickelt, dass man sich vorher das komplette Model-View-Controller Konzept für das Projekt komplett vorher auf Papier bringt und dann erstellt. Danach soll es nicht mehr geändert werden.

Ich bin aber einer der Leute, die von klein auf eine App großziehen und alle paar Tage das Model ändern. Sollte normalerweise ja nicht der Fall sein, aber mir gefällt das und dank South habe ich keine Probleme mehr damit

Maik

@daemonTutorials: Das ist nicht unbedingt Django-spezifisch sondern allgemein bei Datenbanken so. Und damit indirekt auch bei Systemen, die auf Datenbanken aufsetzen.

daemonTutorials hat geschrieben:Also wurde Django so entwickelt, dass man sich vorher das komplette Model-View-Controller Konzept für das Projekt komplett vorher auf Papier bringt und dann erstellt. Danach soll es nicht mehr geändert werden.

Neue Modelle lassen sich noch mit syncdb in die Datenbank bringen. Bei Änderungen an bestehenden Modellen muss man allerdings die Anpassung der Strukturen in der DB manuell vornehmen. Das ist ein wenig aufwändiger, geht aber durchaus.

Ich glaube ich sollte mir das "OpenSource Projektmanagement" Buch von OpenSourcePress für nen 20'ger holen.

Das deutsche Python-Forum

[Django] ForeignKey-Referenz und Datenbank Fehler

[Django] ForeignKey-Referenz und Datenbank Fehler

Re: [Django] ForeignKey-Referenz und Datenbank Fehler

Re: [Django] ForeignKey-Referenz und Datenbank Fehler

Re: [Django] ForeignKey-Referenz und Datenbank Fehler

Re: [Django] ForeignKey-Referenz und Datenbank Fehler

Re: [Django] ForeignKey-Referenz und Datenbank Fehler

Re: [Django] ForeignKey-Referenz und Datenbank Fehler

Re: [Django] ForeignKey-Referenz und Datenbank Fehler

Re: [Django] ForeignKey-Referenz und Datenbank Fehler

Re: [Django] ForeignKey-Referenz und Datenbank Fehler

Re: [Django] ForeignKey-Referenz und Datenbank Fehler

Re: [gelöst] [Django] ForeignKey-Referenz und Datenbank Fehl

Re: [Django] ForeignKey-Referenz und Datenbank Fehler

Re: [Django] ForeignKey-Referenz und Datenbank Fehler