Warum kein SQLalchemy in django?

Sockets, TCP/IP, (XML-)RPC und ähnliche Themen gehören in dieses Forum
ronny
User
Beiträge: 9
Registriert: Donnerstag 19. Juli 2007, 14:50

Mittwoch 29. Oktober 2008, 10:50

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

EDIT (jens): Abgetrennt von http://www.python-forum.de/topic-16476.html
Benutzeravatar
jens
Moderator
Beiträge: 8483
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Mittwoch 29. Oktober 2008, 10:57

sma hat geschrieben: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...

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
sma
User
Beiträge: 3018
Registriert: Montag 19. November 2007, 19:57
Wohnort: Kiel

Mittwoch 29. Oktober 2008, 11:13

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
Benutzeravatar
jens
Moderator
Beiträge: 8483
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Mittwoch 29. Oktober 2008, 11:20

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?

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
ronny
User
Beiträge: 9
Registriert: Donnerstag 19. Juli 2007, 14:50

Mittwoch 29. Oktober 2008, 11:24

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
User
Beiträge: 3018
Registriert: Montag 19. November 2007, 19:57
Wohnort: Kiel

Mittwoch 29. Oktober 2008, 11:24

jens hat geschrieben: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
Benutzeravatar
jens
Moderator
Beiträge: 8483
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Mittwoch 29. Oktober 2008, 11:31

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 ;)

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Leonidas
Administrator
Beiträge: 16024
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Mittwoch 29. Oktober 2008, 11:52

jens hat geschrieben: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.
My god, it's full of CARs! | Leonidasvoice vs Modvoice
lunar

Mittwoch 29. Oktober 2008, 12:33

sma hat geschrieben: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
User
Beiträge: 1454
Registriert: Freitag 22. September 2006, 23:05
Wohnort: ja

Mittwoch 29. Oktober 2008, 13:13

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.

sma hat geschrieben: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.
Benutzeravatar
jens
Moderator
Beiträge: 8483
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Mittwoch 29. Oktober 2008, 13:58

Y0Gi hat geschrieben: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 ;)

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Y0Gi
User
Beiträge: 1454
Registriert: Freitag 22. September 2006, 23:05
Wohnort: ja

Mittwoch 29. Oktober 2008, 15:08

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
Administrator
Beiträge: 16024
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Mittwoch 29. Oktober 2008, 16:02

Y0Gi hat geschrieben: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.
My god, it's full of CARs! | Leonidasvoice vs Modvoice
Y0Gi
User
Beiträge: 1454
Registriert: Freitag 22. September 2006, 23:05
Wohnort: ja

Mittwoch 29. Oktober 2008, 18:30

Damals waren das meiner Erinnerung nach schon welche der besten Komponenten.
Leonidas
Administrator
Beiträge: 16024
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Donnerstag 30. Oktober 2008, 00:06

Y0Gi hat geschrieben: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.
My god, it's full of CARs! | Leonidasvoice vs Modvoice
Antworten