Warum kein SQLalchemy in django?

[ronny]

es gibt nicht ohne grund http://www.sqlalchemy.org/

EDIT (jens): Abgetrennt von http://www.python-forum.de/topic-16476.html

[jens]

Bitte keine Vorschläge, wie ich das mit SQLalchemy o.ä. ermitteln kann, denn das kann und will ich aus Django nicht so ohne weiteres einsetzen.

EDIT: Was ich mich eigentlich Frage, warum nicht mehr darauf hin gearbeitet wird SQLalchemy direkt in django einzuarbeiten und das bestehende ORM in die Tonne zu hauen. Einen branch http://code.djangoproject.com/browser/d ... sqlalchemy gab es ja mal, aber der it seid zwei Jahren tot.
Aber das ist django. Da wird nix fertiges/externes genutzt, da muß alles selber gemacht werden...

[sma]

Das klingt jetzt so, als wäre das gebaut worden, weil Djangos ORM zu simpel ist :) Genauso könnte man auf Storm verweisen. Beides hilft aber nicht, wenn man für Django wiederverwendbare Anwendungen schreiben will.

Stefan

[jens]

Nein, so meinte ich das nicht.

SQLalchemy (Ich hab es mit nie angesehen) soll django's ORM überlegen sein, oder?

Ich frage mich halt, warum man am django ORM weiter entwickelt und nicht auf das fertige SQLalchemy zurück greift?
Warum ist der django branch "sqlalchemy" nicht weiter verfolgt worden?

Macht es nicht mehr Sinn, Zeit damit zu verbringen SQLalchemy in django zu integrieren, als am django ORM weiter zu machen?

[ronny]

die django core devs wollen ned - die behalten lieber ihre halb-fertigen hacks

ich habe das ganze dann aufgegeben - django ist eben "foul batteries included"

sqlalchemy ist einfach nur überlegen

[sma]

EDIT: Was ich mich eigentlich Frage, warum nicht mehr darauf hin gearbeitet wird SQLalchemy direkt in django einzuarbeiten

mtrier hat django-sqlalchemy begonnen, ist aber noch ganz am Anfang.

Der Hauptgrund, das bestehende ORM nicht in die Tonne zu hauen ist sicherlich, dass man keine so extreme Abhängigkeit im Projekt haben will. Djangos Stärke liegt ja in der starken Integration. So kann man natürlich auch heute schon SQLalchemy benutzen, verliert dann aber Admin-UI, Form-Bau und -Validierung, usw. und landet im Prinzip bei etwas wie Werkzeug ;)

Der bestehende ORM sei zudem weniger stark von SQL abhängig als (logischerweise) SQLalchemy und damit potentiell auch in der Lage transparent auf andere Backends wie Googles Bigtable zuzugreifen, heißt es.

Davon abgesehen: Sie sind ja zu 85% am Ziel. Es fehlen eigentlich nur noch Aggregationen und vielleicht Subqueries. Dann noch ein transaktionssicheres get_or_create... transaktionssicheres Inkrementieren... wiederholbare Transaktionen... aber das haben auch kaum irgendwelche anderen Datenbank-basierten Webanwendungen. Ich glaube ja, 90% aller PHP-basierten Lösungen sind nicht transaktionssicher.

Stefan

[jens]

OK, externe Abhängigkeiten sind doof. Deswegen hab ich in PyLucid auch wenig externe Dinge eingebaut.

Eine Lösung wäre es aber SQLAlchemy als fork sich einzuverleiben. Auch wenn es gegenüber den Entwicklern nicht so nett ist.

Aber gut, django 1.1 soll ja nächstes Jahr im März fertig sein, von daher ist es jetzt auch egal

[Leonidas]

EDIT: Was ich mich eigentlich Frage, warum nicht mehr darauf hin gearbeitet wird SQLalchemy direkt in django einzuarbeiten und das bestehende ORM in die Tonne zu hauen.

Letztendlich ist das wohl recht einfach zu erklären. Jeder der mehr Flexibilität braucht als das ORM bietet, schraubt daran herum bis er irgendwann das Django-ORM in die Tonne haut und direkt SQLAlchemy verwendet. Vielleicht haut man dann auch gleich Django in die Tonne, weil ohne Admin-UI und ORM kann es nichts besonderes mehr. An dieser Stelle nimmt man dann ein anderes Framework. Wenn ich in meinen Applikationen nicht das Django-ORM nutzen würde, dann würde ich wohl auch kein Django nutzen, denn die Templates habe ich auch schon ausgetauscht. Die fand ich viel einschränkender als das ORM; aber das hängt natürlich vom Einsatzzweck ab.

[lunar]

Der Hauptgrund, das bestehende ORM nicht in die Tonne zu hauen ist sicherlich, dass man keine so extreme Abhängigkeit im Projekt haben will. Djangos Stärke liegt ja in der starken Integration. So kann man natürlich auch heute schon SQLalchemy benutzen, verliert dann aber Admin-UI, Form-Bau und -Validierung, usw. und landet im Prinzip bei etwas wie Werkzeug

Was hindert die Entwickler daran, diese Komponenten zu portieren?

Die Problematik der externen Abhängigkeiten sehe ich jetzt auch nicht so wirklich. Pylons hat dutzende Abhängigkeiten und ist dank easy_install auch nicht schwerer zu installieren als Django.

Man sollte auch daran denken, dass den Entwicklern umso mehr Ressourcen zur Verfügung stehen, je mehr sie auslagern. Angenommen, Django würde SQLAlchemy und Jinja2 integrieren, müssten sich die Entwickler um zwei Kernkomponenten nicht mehr kümmern und könnten sich umso mehr auf das konzentrieren, was Django wirklich herausragen lässt, wie z.B. das Admin-Interface.

So aber hilft mir das Admin-UI auch nichts, wenn ich Django aufgrund seiner limitierten Kernkomponenten nicht nutzen kann/will. Ich jedenfalls halte es momentan mit ronny.

Der bestehende ORM sei zudem weniger stark von SQL abhängig als (logischerweise) SQLalchemy und damit potentiell auch in der Lage transparent auf andere Backends wie Googles Bigtable zuzugreifen, heißt es.

Tja, nun stellt sich die Frage, was die potentiellen (und nicht implementierten) Möglichkeiten nutzen, wenn das ORM ganz konkrete Probleme hat.

[Y0Gi]

Siehste, sma, und jetzt bist du genau an dem Punkt, vor dem ich bei Django-Empfehlungen gelegentlich warne.

Mit TurboGears und Pylons gibt es Projekte, die das Verbindungen von Best-of-Breed-Komponenten praktizieren. Letztlich ist es immer irgendwo ein Kompromiss, je nachdem ob man ein externes Projekt einbindet und bei dortigen Änderungen den eigenen Gluecode hinterher patcht oder ob man was eigenes, unterlegenes entwickelt und ausliefert, über das man die volle Kontrolle hat und das keine zusätzlichen Abhängigkeiten mit sich bringt.

Wenn man ein neues Projekt beginnt, kann man beim Erreichen solcher Grenzen vielleicht noch reagieren, aber will man nach drei Jahren ein neues, komplexeres Feature hinzufügen, sieht das mit einem Framework-Wechsel eher schlecht aus. Stattdessen Plain-SQL in einer ORM-Applikation in größerem Umfang einzusetzen ist für mich keine Option (mit SA kann ich auch diverse Queries für Statistiken o.ä. objektorientert [nicht zwingend via ORM] formulieren), da ich dann plötzlich das Model redundant führe und bei Änderungen den doppelten Spaß habe.

Das klingt jetzt so, als wäre das gebaut worden, weil Djangos ORM zu simpel ist Genauso könnte man auf Storm verweisen.

Gerade gestern habe ich gelesen, dass Storm ursprünglich entwickelt wurde, um Dinge zu tun, die SA zu dem Zeitpunkt noch nicht konnte. Dennoch ist Storm viel limitierter, hat aber auch ein deutlich begrenzteres Einsatzgebiet.

[jens]

Mit TurboGears und Pylons gibt es Projekte, die das Verbindungen von Best-of-Breed-Komponenten praktizieren.

Wobei gerade TurboGears ein Beispiel dafür ist, das sowas auch schief gehen kann

[Y0Gi]

Als es neu war, war es ein ziemlicher Erfolg. Ich frage mich, woran TG wirklich scheitert. Daran, dass alle Komponenten gegen die neuere, bessere Generation ausgetauscht wurden? Oder dass man immer hinterher flickt und mit dem Stand der Technik nicht Schritt halten kann (was bei Pylons einigermaßen klappt)?

[Leonidas]

Ich frage mich, woran TG wirklich scheitert. Daran, dass alle Komponenten gegen die neuere, bessere Generation ausgetauscht wurden?

Vielleicht war es ja eben die hmm, eher schlechte Wahl der Standard-Komponenten. Gut, damals gab es nicht so gute wie heute, so gesehen hat TG den Weg für Pylons geebnet.

[Y0Gi]

Damals waren das meiner Erinnerung nach schon welche der besten Komponenten.

[Leonidas]

Damals waren das meiner Erinnerung nach schon welche der besten Komponenten.

Also CherryPy hatte damals Threading-Probleme (bis einschließlich Version 2, vielleicht auch spätere), Kid hat doch eigenlich nie richtig gut funktioniert, bis es dann irgendwann nicht mehr maintained wurde. SQLObject wurde kurz danach verwaist (also es scheint da noch Maintainer zu geben, aber nachdem Ian das zu blöd wurde gings nicht mehr weiter) und Mochikit hat nie sonderlich Popularität erlangen können und wurde binnen kürzester Zeit von jQuery nachdem es released wurde überholt.

[Y0Gi]

Zu CherryPy gab es damals keine mir bekannte Alternative (die Zope-Welt lassen wir mal außen vor, die hatten sowieso schon alles ein halbes Jahrzehnt vorher). SQLObject wurde "zuletzt" von einem Russen gepflegt, doch klar, da ging nicht mehr viel. Zu TG-Release-Zeiten war SO aber vorne mit dabei, wenn nicht *das* populärste Python-ORM. Kid war für mich ein besseres (Simple)TAL mit ganz knapp hinnehmbaren Schwächen, aber im XML-Bereich sonst konkurrenzlos; deswegen war ich auch einer der ersten, die so über Genshi "geraved" haben

[Leonidas]

Das meinte ich eben mit Weg für Pylons ebnen. Jetzt hat es sich etwas mehr herauskristallisiert, was gekommen ist um zu bleiben.

[zero-one]

Ich will mal ne ganz doofe Frage in den Raum werfen... Pylons hat anscheinend alles was man braucht... und vereint anscheindend auch die besten Komponenten miteinander... wieso findet es dann nicht wirklich Verbreitung? Ich meine hier im Forum nutzt es anscheinend auch so gut wie niemand...

gruessle

[lunar]

Ich zumindest nutze es ohne Probleme und bin zufrieden damit ...

Im Übrigen würde ich nicht aus der Anzahl der Fragen hier im Forum auf die Verbreitung eines Frameworks schließen. Es entwickelt ja auch niemand mehr ernsthaft reine CGI-Anwendungen, trotzdem tauchen ab und zu noch Fragen dazu auf ...

Eine "große" Seite, die pylons nutzt, ist beispielsweise reddit.com, deren Code du auch unter code.reddit.com anschauen kannst.

[Darii]

Turbogears 2 wird ja sowohl Pylons als auch SA verwenden.