Der beste Weg, um die Ordner mit den SQLAlchemy-Modellen zu organisieren

Question

Ich benutze SQLAlchemy bei der Arbeit und es macht den Job wirklich gut. Jetzt denke ich über Best Practices nach.

Vorerst erstelle ich ein Modul all SQLA Zeug hält:

my_model 
     |__ __init__.py 
     |__ _config.py <<<<< contains LOGIN, HOST, and a MetaData instance 
     |__ table1.py <<<<< contains the class, the model and the mapper for table1 
     |__ table2.py <<<<< contains the class, the model and the mapper for table2 
     [...] 

Nun, ich weiß wirklich nicht, ob es der beste Weg, es zu tun. Ich möchte die Klassen mit einer feinen Granularität laden und sicher sein, eine Verbindung nur mit der db usw. zu erstellen.

Hier sind alle Klassen getrennt, aber alle importieren _config und ich frage mich, ob es eine gute Sache ist .

Darüber hinaus möchte ich in der Lage sein, Unterklassen der Modellklassen zu erstellen, die unabhängig voneinander gespeichert werden können, ohne jedes Mal mit dem Mapper zu verfahren. Wie kann ich das machen ?

Für jetzt habe ich sie nur in der gleichen Datei und ich muss einen anderen Mapper erstellen, aber der erste Mapper wird immer noch jedes Mal aufgerufen. Das gleiche würde gehen, wenn ich die Elternklasse importieren müsste, weil der Mapper beim Import ausgelöst wird. Wenn ich die Klasse nicht für den Zugriff auf Daten verwende, ist es nicht überhitzt, sie jedes Mal abzubilden?

Ich möchte auch vermeiden, Elixir zu verwenden, bitte.

Answer 1

Persönlich mag ich die Datenbank/ORM-Logik aus den Modellklassen heraushalten. Es macht sie einfacher zu testen. Ich habe normalerweise etwas wie eine types.py, die die Typen definiert, die in meiner Anwendung verwendet werden, aber unabhängig von der Datenbank.

dann in der Regel gibt es einen db.py oder etwas ähnliches, die die Session Klasse und den Rest des Codes hat erforderlich, um die Datenbank einzurichten, einschließlich aller Mapper usw.

Keiner der anderen Module mit Ausnahme derjenigen, die ausführen Datenbankoperationen müssen das Modul db importieren, und das Vorhandensein der Datenbank ist den meisten Anwendungsklassen völlig verborgen.

Soweit ich weiß, können Sie keine Unterklassen erstellen, ohne den Mapper zu ändern. SQLAlchemy hat keine Möglichkeit zu ermitteln, welche Unterklasse beim Ausführen einer Abfrage aus der Datenbank abgerufen werden soll, und Sie müssen die Unterklasse angeben können, wenn Sie die Daten trotzdem speichern.

Ich habe nicht wirklich irgendwelche Probleme auftreten aus dem Aufruf aller Mapper auf einmal von der Haupt db Modul, so glaube ich nicht, dass sie die ganze Zeit Initialisierung ist wirklich ein Problem, es sei denn Sie tatsächlich identifizieren es als Engpass. Meiner Erfahrung nach ist eine andere Verarbeitung ein viel größerer Faktor als der kleinere Mapper-Overhead.