ORM - SQLAlchemy vs. Storm vs. Autumn

[noisefloor]

Hallo,

ich spiele gerade mit dem Gedanken, meine Anwendungen von rohem SQL auf ein ORM umzustellen. Hier im Forum wird SQLAlchemy immer wieder empfohlen... Wenn ich die Doku lesen finde ich persönlich aber Storm oder Autumn deutlicher einfacher zu verstehen...

Was spricht eigentlich genau für SQLAlchemy. Es steht zwar an diversen Stellen im Web "very powerfull"... was immer das auch heißt.

Die Tabellen und Anwendungen in meinen Anwendungen sind alle rel. übersichtlich und rel. klein (=wenig Spalten, wenig Tabellen). Bei den Queries kommt ich bis auf ganz wenig Ausnahmen mit normalen "SELECT"-Statements aus, brauche nur ab und an eine Abfrage mit einem "JOIN".

Gruß, noisefloor

[DasIch]

SQLAlchemy ist nicht einfach ein ORM, es bietet dir Pools für Verbindungen und eine Abstraktionsschicht über SQL. Das ORM ist nur ein zusätzliches Feature basierend auf dieser Abstraktionsschicht. Daher ist es sehr einfach das ORM anzupassen oder zu erweitern, sowie Queries zu optimieren.

[Dauerbaustelle]

Kommt halt drauf an was du haben willst. Ich würde für nen kleines Projekt (was auch nicht in absehbarer Zeit viel größer wird) keinenfalls SQLAlchemy nutzen, dafür ist der ganze Setup-Overhead viel zu groß.

Ganz nett fand ich peewee. Das ist im Prinzip ein Django-ORM-Abklatsch, aber mit expliziten statt impliziten JOINs und (zur Zeit noch) SQLite-only. In der Spielklasse gibt es glaube ich noch einige andere ORMs für SQL.

Falls es nicht SQL sein muss, könntest du dir auch mal die ORMs für MongoDB ansehen, da gibts mittlerweile auch ein paar (am bekanntesten ist wohl MongoEngine).

[Leonidas]

Ist auch die Frage welches ORM auch morgen noch lebt. Erinnert sich wer an GeniusSQL? Dejavu? SQLObject?

[noisefloor]

Hallo,

Ist auch die Frage welches ORM auch morgen noch lebt.

Da sollte man zumindest mit Storm auf der sicheren Seite sein, weil Canonical dahinter steht. Und die stehen ja bekanntlich darauf, eigene Software zu entwickeln.

Gruß, noisefloor

[donmarten]

Ist auch die Frage welches ORM auch morgen noch lebt. Erinnert sich wer an GeniusSQL? Dejavu? SQLObject?

SQLObject wurde erst am 06.12 auf die Version 0.15 aktualisiert.

[Leonidas]

SQLObject wurde erst am 06.12 auf die Version 0.15 aktualisiert.

Trotzdem habe ich bei SQLObject den Eindruck dass seitdem ianb das nicht mehr maintained, das Ding B-Ware geworden ist. Die Seite von SQLObject sieht noch genauso aus wie vor ein, zwei Jahren.

[lunar]

@dauerbaustelle: Lieber der „Setup-Overhead“ (was immer das auch konkret sein soll) von SQLAlchemy anstatt irgendein kleines Spielzeug-ORM, welches gerade mal so zwei Monate alt ist. Da weiß man wenigstens, woran man ist ...

@noisefloor: Welches ORM Du verwendest, ist bei kleinen Projekten mehr oder weniger egal, solange das ORM etabliert ist und gewartet wird. Vorteile hat SQLAlchemy erst bei großen Projekten. Allerdings ist SQLAlchemy eben mehr als nur ein ORM, und bietet insbesondere die SQL Expression Language genannte Abstraktionsschicht über SQL, die SQL-Ausdrücke als Python-Ausdrücke darstellt. Das ist meines Erachtens einer der wesentlichen Vorteile von SQLAlchemy, denn es erleichtert bereits die Arbeit mit SQL selbst, ohne wesentlichen zusätzliche Komplexität einzuführen.

Schließlich ist SQL selbst ungeachtet des Hypes um ORMs keineswegs schlecht, und oft genug sinnvoller als ein ORM.

[Dauerbaustelle]

@dauerbaustelle: Lieber der „Setup-Overhead“ (was immer das auch konkret sein soll)

Ich meine damit eigentlich hauptsächlich das "Getting Started". Wie definiere ich meine Models, Tabellen, wie funktioniert das Mapping, wie mache Queries und so weiter.

Mit SQLAlchemy braucht man da viel mehr Zeit und Nerven als z.B. mit dem Django-ORM -- natürlich hat SQLAlchemy unendlich viele Vorteile, aber ein kleineres Low-Traffic-Projekt mit vielleicht 10 verschiedenen Queries kommt man gar nicht wirklich dazu, die auszunutzen.

Außerdem finde ich die Query-API von SQLAlchemy ziemlich eklig. Nicht, weil da jemand von den SQLAlchemy-Leuten Schrott gebaut hat, sondern weil man halt überall den SQL-Gestank durchriecht. Ich will gar nicht wissen, dass da im Hintergrund SQL läuft... mir wird sonst schnell übel.

anstatt irgendein kleines Spielzeug-ORM, welches gerade mal so zwei Monate alt ist. Da weiß man wenigstens, woran man ist ...

Das impliziert ja, dass aus "Bleeding Edge" "buggy" folgert. Das ist genau der Denkfehler, den Debian macht. Software wird nicht stabiler, wenn man nur lange genug wartet.

Natürlich ist etablierte Software oft mit weniger Risiko verbunden, aber besonders bei jungen Projekten ist es auch kein Problem, Fehler selbständig zu beheben, weil die Codebasis (hoffentlich :-) übersichtlicher ist als bei Projekten, die über die Jahre hinweg irgendwelche Workahacks und Features hingefügt haben.

Und so wie ich das jetzt verstanden habe baut noisefloor keine Projekte mit 100-Prozent-Verfügbarkeits-Anforderung.

[noisefloor]

Hallo,

Und so wie ich das jetzt verstanden habe baut noisefloor keine Projekte mit 100-Prozent-Verfügbarkeits-Anforderung.

Nee, es sind drei kleine Webapplikation bei uns in der Firma im Intranet. Performance ist nicht gefragt, weil da drauf max 20 Seite pro Tag abgerufen werden.

Es besteht in der Tat keine dringende Notwendigkeit für ein ORM - es geht auch sehr gut mit SQL-only. Das ORM ist rein Interesse halber und um was neues auzuprobieren (man weiß ja nie, was in der Zukunft kommt). Was mich ja auch zur ursprünglichen Frage bewegt hat, weil SQLAlchemy, wie Dauerbaustelle ja sagt, dass "Getting Started" nicht gerade trivial ist.

BTW: nutzt hier eigentlich irgendwer Storm oder Autumn? Ich kann mich nicht daran erinnern, hier im Forum dazu mal 'ne Frage gesehen zu haben...

Jedenfalls Danke schon mal für eure Antworten.

Gruß, noisefloor

[Leonidas]

anstatt irgendein kleines Spielzeug-ORM, welches gerade mal so zwei Monate alt ist. Da weiß man wenigstens, woran man ist ...

Das impliziert ja, dass aus "Bleeding Edge" "buggy" folgert. Das ist genau der Denkfehler, den Debian macht. Software wird nicht stabiler, wenn man nur lange genug wartet.

Nein, aber wenn die Software in Verwendung ist und aktiv maintained ist, dann ist wie Wahrscheinlichkeit oftmals geringer, dass man in irgendwelche Bugs fällt als bei irgendwas brandneuem. Außerdem verstehe ich nicht den Seitenhieb auf Debian, Debian paketiert durchaus aktuelle Software in Debian unstable. Sie nehmen nicht das erste Release, warten bis das outdated ist und shippen es dann.

Natürlich ist etablierte Software oft mit weniger Risiko verbunden, aber besonders bei jungen Projekten ist es auch kein Problem, Fehler selbständig zu beheben, weil die Codebasis (hoffentlich übersichtlicher ist als bei Projekten, die über die Jahre hinweg irgendwelche Workahacks und Features hingefügt haben.

Klar, es ist auch kein Problem einen Tag Wert Daten zu verlieren ohne es zu merken weil das junge Projekt irgendwelche Bugs hat (siehe CouchDB 1.0). Und außerdem will man natürlich auch selbst Bugs fixen und sie dann Upstream schicken oder eigene Forks maintainen, statt Software zu nutzen die diese Bugs nicht (mehr) hat.

Ich meine, ok, wenn man mit der existierenden, etablierten Software irgendwelche Probleme hat, ok, aber Alternativen zu nutzen um Alternativen zu nutzen rächt sich am Schluss eh wieder. Schon allein wegen der kleineren Community, wie noiseflor eben festgestellt hat.

[Dauerbaustelle]

Außerdem verstehe ich nicht den Seitenhieb auf Debian, Debian paketiert durchaus aktuelle Software in Debian unstable. Sie nehmen nicht das erste Release, warten bis das outdated ist und shippen es dann.

Darauf läufts ja aber hinaus. Sieht man an Firefox zum Beispiel, Debian hat eigentlich nur veraltete Versionen davon drin. Ubuntu hat ja mittlerweile gemerkt dass das überhaupt nix bringt und nur dazu führt, dass die Leute sich mit irgendwelchen halboffiziellen Paketen Dependency-Chaos herbeiführen.

Klar, es ist auch kein Problem einen Tag Wert Daten zu verlieren ohne es zu merken weil das junge Projekt irgendwelche Bugs hat (siehe CouchDB 1.0).

Das ist aber kein Problem von Bleeding Edge -- sogar in so etablierten und ausgereiften Projekten wie Linux finden sich regelmäßig die abartigsten Fehler (ich glaube mindestens drei Bugs, die dazu führen, dass man unberechtigter Weise an Root-Rechte kommt, innerhalb dieses Jahres).

Und außerdem will man natürlich auch selbst Bugs fixen

Also ich mag das :-) Ich sehe aber natürlich schon ein, dass diese Haltung Produktiveinsatz-inkompatibel ist ;-)

Ist halt ne Abwägungssache: Nehme ich die Komplexität etablierter oder das Bugrisiko neuer Software in Kauf? Optimal wäre natürlich etablierte, simple Software. Nur vergisst man das viel zu oft :-(

[Leonidas]

Außerdem verstehe ich nicht den Seitenhieb auf Debian, Debian paketiert durchaus aktuelle Software in Debian unstable. Sie nehmen nicht das erste Release, warten bis das outdated ist und shippen es dann.

Darauf läufts ja aber hinaus. Sieht man an Firefox zum Beispiel, Debian hat eigentlich nur veraltete Versionen davon drin. Ubuntu hat ja mittlerweile gemerkt dass das überhaupt nix bringt und nur dazu führt, dass die Leute sich mit irgendwelchen halboffiziellen Paketen Dependency-Chaos herbeiführen.

Davon abgesehen dass ich Debian stable wohl eher nicht für den Desktopeinsatz hernehmen würde hat Debian die Security-Patches zurückportiert und shippt inzwischen auch die "neueren" Versionen, weil Mozilla die Sicherheitsbugfixes nicht in brauchbaren Patches bereitstellt. Aber das hat jetzt nichts mehr mit dem eigentlichen Thema zu tun.

Klar, es ist auch kein Problem einen Tag Wert Daten zu verlieren ohne es zu merken weil das junge Projekt irgendwelche Bugs hat (siehe CouchDB 1.0).

Das ist aber kein Problem von Bleeding Edge -- sogar in so etablierten und ausgereiften Projekten wie Linux finden sich regelmäßig die abartigsten Fehler (ich glaube mindestens drei Bugs, die dazu führen, dass man unberechtigter Weise an Root-Rechte kommt, innerhalb dieses Jahres).

Ja richtig, aber die Wahrscheinlichkeit dass der Code relativ ausgereift ist, ist bei größeren Projekten halt höher.

[BlackJack]

Bis jetzt wurde glaube ich `Elixir` hier noch nicht erwähnt -- ein ORM, das auf SQLAlchemy aufbaut um das, was hier als "Setup-Overhead" bezeichnet wurde, zu beseitigen.

Zum "riechenden" SQL -- ich hatte bei Django die Erfahrung gemacht, dass ich Probleme bekommen habe, wenn ich die Objekte wie gewohnt einfach so nach OOP-Gesichtspunkten entwerfe und nicht im Blick behalte, dass da eine Relationale-DB im Hintergrund ist. Ich denke wenn man das nicht haben möchte, sollte man besser gleich auf eine Objekt-DB setzen. Und bei nicht ganz trivialen Sachen kommt man IMHO auch bei einem ORM nicht darum herum sich Gedanken um das SQL dahinter zu machen, um ein wenig an den Anfragen schrauben zu können, wenn etwas hängt, weil die automatisch erzeugten "generischen" Objektanfragen zu umständlich zum Ziel kommen; zu viele Daten abfragen, die man letztlich eigentlich gar nicht benötigt; oder zu häufig einzelne Zugriffe erzeugen. Und dann ist es schon ganz praktisch wenn man sich a) das SQL anzeigen lassen kann und es b) nicht total kryptisch ist wie das zustande kommt, so dass man es von Python aus beeinflussen kann, ohne dass man tatsächlich SQL schreiben muss.

[lunar]

@Dauerbaustelle: Im Regelfall hat man mit dem eigenen Projekt schon genug zu tun, als das man sich auch noch um Fehler in anderen Projekten kümmern könnte. Darin liegt ja gerade der Sinn in der Verwendung von Drittbibliotheken. Man gibt Verantwortung für bestimmte Funktionalität in die Hände einer gut getesteten und etablierten Bibliothek, um sich Arbeit zu ersparen.

Ich habe im Übrigen keinesfalls behauptet, dass aus „bleeding edge buggy folgern“ würde. Lies den betreffenden Satz im meinem Beitrag nochmal ganz genau, und denke darüber nach, was ich damit wirklich sagen wollte (und lass dieses Mal Debian aus dem Spiel, davon hat niemand gesprochen, und mit dem Thema hat es erst recht nichts zu tun). Es geht schlicht nur darum, dass eine etablierte Bibliothek, welche über lange Zeit von verschiedenen Organisationen in vielfältigen Umgebungen für verschiedene Projekte verwendet wurde, ein hohes Maß an Vertrauen genießt, auch weil viele kritische Fehler bereits von Dritten gefunden und behoben wurden, bevor man selbst sie überhaupt zu Gesicht bekommt. Dieses Vertrauen fehlt bei einem jungen Projekt, dass keine solide Nutzerbasis besitzt und von einer relativ unbekannten Einzelperson geschrieben wurde.

Das Projekt kann noch so „cool“ sein, Coolness ist nun mal kein sinnvoller Maßstab bei der Entwicklung, und man verwendet Bibliotheken auch nicht um ihrer selbst willen, sondern zum Vorteil des eigenen Projekts.

Zum Thema ORM und SQL hat BlackJack bereits alles gesagt, was zu sagen ist.

[Hyperion]

Bis jetzt wurde glaube ich `Elixir` hier noch nicht erwähnt -- ein ORM, das auf SQLAlchemy aufbaut um das, was hier als "Setup-Overhead" bezeichnet wurde, zu beseitigen.

Auch wenn es in SQLAlchemy mittlerweile ein deklaratives Vorgehen gibt, empfand ich Elixir da deutlich angenehmer, auch beim Erstellen von n:m-Relationen; nur zusätzliche Attribute bei n:m habe ich nie wirklich hinbekommen.

Ich würde aber mal sagen, dass es sich lohnt, sich einen ORM wie SQLAlchemy mal anzugucken und sich auch mal durch den Overhead durchzuquälen. Ohne sich wirklich mit etwas befasst zu haben, kann man den (Mehr-)Wert immer schlecht einschätzen.

[noisefloor]

Hallo,

Update:

habe mich mal ein bisschen mit SQLAlchemy beschäftigt (der Mensch ist doch ein Herdentier ). Es ist gar nicht so kompliziert, wie es zuerst wirkt. Und die Doku ist auch ziemlich verständlich geschrieben.

Ob ich es am Ende wirklich einsetze, d.h. brauche weiß ich auch noch nicht. Mal schauen.

Gruß, noisefloor

[lunar]

Es ist gar nicht so kompliziert, wie es zuerst wirkt.

Das gilt jetzt so ziemlich für fast alles, mit dem man sich näher beschäftigt hat ...

[noisefloor]

Hallo,

Das gilt jetzt so ziemlich für fast alles, mit dem man sich näher beschäftigt hat ...

Ja, bekannte Ausnahmen sind:

• Inhaltsverzeichnisse für PDFs mit ReportLab erstellen
• Windows API
• Weltfrieden
• Frauen

Gruß, noisefloor

[Hyperion]

[*]Frauen[/list]

Das ist aber alternierend Oder zumindest schwankend...

Prinzipiell kommt es im Python-Umfeld aber schon auch auf die API / das Modul an. Manche sind einfach schlecht designed und deshalb kompliziert; wenn dann noch die Doku mau ist, wirds nur dadurch besser, indem man sich damit nicht näher befasst und sich Alternativen sucht