Das deutsche Python-Forum

Hallo,

meego hat geschrieben:Dies hier: Link.

Klar geht das, steht auch so in der WTForms Doku

Hat das weniger Ressourcenverbrauch?

"Premature optimization is the root of all evil" - bring' dein Projekt doch erst mal überhaupt zum Laufen, bevor due dir über Optimierungen im Nana-Sekunden Berech gedanken machst...

Gruß, noisefloor

Hallo

BlackJack hat geschrieben:@meego: Na Du hast halt nicht alle Sprachen zu einer ID in einem Datensatz sondern für jede ID und Sprache einen eigenen Datensatz.

Code: Alles auswählen

1 en House
1 de Haus
2 en Car
2 de Auto

Wie nennt sich der zusammengesetzte Primärschlüssel auf Englisch? Was ist von der ID-Redundanz zu halten?

ob man unsinnigen, zu komplizierten Code schreibt, oder den genau für diesen Fall vorgesehenen.

Das Wörterbuch muss man ja mit beiden Fällen erstellen. Vorgesehen sind gemäss Links beide Methoden:
Link Link

meego hat geschrieben:Wie nennt sich der zusammengesetzte Primärschlüssel auf Englisch?

Composite primary key.

meego hat geschrieben:Vorgesehen sind gemäss Links beide Methoden:

Was heißt "vorgesehen"? Es gibt Fälle, in denen die update-Funktion durchaus Sinn macht. Dein Fall gehört jedoch nicht dazu.

@meego: Nein, nur bei `update()` wird ein zusätzliches *unnötiges* Wörterbuch erstellt, extra nur damit man damit `update()` aufrufen kann.

@BlackJack:

dict = {}
dict[key] = "value"

? Oder meinst du die Update-Methode erzeugt im Speicher immer ein neues Dict?

Der ComposityKey scheint wirklich nicht ganz simpel (ich habe ca. 20 Optionen) und als Rückgabewert benötige ich dann doch nur die ID:

@meego: Nicht die `update()`-Methode sondern *Du* als Programmierer erzeugst ein Wörterbuch und rufst damit die `update()`-Methode auf. *Siehst* Du das nicht? Was ist an einem zusammengesetzen Primärschlüssel denn kompliziert? Und wieso brauchst Du als Rückgabewert die ID? Doch wohl eher den Text der zu dem zusammengesetzten Primärschlüssel gehört. Alternativ kann man natürlich auch noch zusätzlich einen künstlichen Primärschlüssel einführen und auf die beiden indentifizierenden Spalten einen Index legen. Also bei Deinem Beispiel. An der N:M-”Zwischentabelle” die Du da von irgendwo kopiert hast, macht so etwas natürlich keinen Sinn. Also eigentlich auch bei Deinem Beispiel nicht wirklich.

@BlackJack: Ja schon, aber es sind für mich in beiden Fällen zwei Linien Code.

Es ist eine Wohnungoptionentabelle zur Wohnungstabelle. Es ist immer eine Option pro Wohnung möglich. Die einzelnen Optionen sind ziemlich fix und liegen in mehreren Sprachen vor, wenn man das über die Datenbank lösen will. Die ID der Option ist ein FK in der Wohnungstabelle. Wozu benötige ich den Text?

Das Beispiel ist aus der Peewee Doku, wie man 'nen zusammengesetzten Primärschlüssel erstellt.

@meego: Den Text benötigst Du zum Anzeigen. Sonst würdest Du den ja gar nicht benötigen. Das heisst Du willst ID + Text wissen. Aber wie schon gesagt würde ich Übersetzungen in der Regel anders lösen.

@BlackJack: Jup, aber ich meinte vom Inputformular zurück benötige ich ihn nicht mehr (könnte ich dann jederzeit abfragen, oder?). Kannst du grundsätzlich erläutern wie Babel funktioniert? Ich nehme mal an es wäre das: Link. Ist aber völlig unverständlich geschrieben.

@meego: Nee, ich denke gettext & Co sind nicht mal eben in zwei Sätzen erklärt. Das ist ja auch ein kompliziertes Thema. Die meisten Leute kennen ja nur zwei, drei Sprachen und haben keine Ahnung was es alles an Regeln und Ausnahmen in anderen Sprachen geben kann, zum Beispiel was Ein- und Mehrzahl angeht bzw. dass das bei einigen Sprachen gar keine binäre Sache ist, sondern das da noch mehr unterschieden wird.

@BlackJack: Kurze Rede, langer Sinn: Du empfiehlst mir die Tabelle erst einmal auf id/deutscher Text zu beschränken und mich dann später um Sprachen zu kümmern..

Wieso stellen ORMs eigentlich nicht selber Methoden für die Validationsprüfung zur Verfügung?

@meego: Tun sie doch. Zudem kann man noch auf Datenbankebene constraints setzen, wenn sie unterstützt werden.

@meego: Zum einen weil ORMs nicht wissen wo die Daten herkommen und bei vielen ”Quellen” bereits Mechanismen zur Validierung bereitstehen und auf der anderen Seite auch auf der Seite der Datenbank über CONSTRAINT Prüfungen möglich sind, Spezielle (NOT NULL, UNIQUE, PRIMARY KEY) oder auch allgemein formulierbare mit CHECK.

Ausserdem bietet SQLAlchemy beispielsweise durchaus die Möglichkeit über den `sqlalchemy.orm.validates()`-Dekorator Methoden zur Validierung von Attributwerten zu schreiben.

Hallo,

meego hat geschrieben:Wieso stellen ORMs eigentlich nicht selber Methoden für die Validationsprüfung zur Verfügung?

In WTForms zu validieren hat außerdem den Vorteil, dass WTForms bei Fehlern in der Validierung direkt ein neues Formular inkl. Fehlerausgabe generien kann - das kann ein ORM halt nicht, weil's eine Ebene tiefer sitzt.

meego hat geschrieben:Kurze Rede, langer Sinn: Du empfiehlst mir die Tabelle erst einmal auf id/deutscher Text zu beschränken und mich dann später um Sprachen zu kümmern..

Alsp ich würde das ganze schon mal an einer Mini-Applikation (muss ja nicht unbedingt dein Immobilien-Projekt sein) üben, damit du siehst, wie das funktioniert. Außerdem könnte es ja auch sein, dass du damit überhaupt nicht klar kommst, was wiederum einfluss auf den Entwurf den Applikation / Datenbank haben könnten.

Und der Vollständigkeit halber sei noch angemerkt, dass Django i18n ootb unterstützt.

Gruß, noisefloor

noisefloor hat geschrieben:Und der Vollständigkeit halber sei noch angemerkt, dass Django i18n ootb unterstützt.

Übersetzung: Wenn du Django benutzen würdest, wie seit Wochen empfohlen, müsstest du auch das Rad "Verwaltung übersetzter Texte" nicht neu erfinden.

Gibt auch ein paar django apps: https://www.djangopackages.com/grids/g/i18n/

i18n ist halt auch ein komplexes Thema...

Hallo

In WTForms zu validieren hat außerdem den Vorteil, dass WTForms bei Fehlern in der Validierung direkt ein neues Formular inkl. Fehlerausgabe generien kann - das kann ein ORM halt nicht, weil's eine Ebene tiefer sitzt.

Es könnte diese Methoden vielleicht auch implementieren und selber die Formularfelder erzeugen..

Übersetzung: Wenn du Django benutzen würdest, wie seit Wochen empfohlen, müsstest du auch das Rad "Verwaltung übersetzter Texte" nicht neu erfinden.

Will ich auch nicht. Und dafür müsste ich dann vermutlich erst einmal ein halbes Jahr lang das wesentlich unintuitivere Django erlernen, um überhaupt etwas damit anstellen zu können.

Hallo,

meego hat geschrieben:Es könnte diese Methoden vielleicht auch implementieren und selber die Formularfelder erzeugen..

Äh... heißt was genau? Verstehe ich gerade nicht.

EDIT: bezieht das "Es" auf das ORM?

Gruß, noisefloor