sqlalchemy - Erfahrungen???

[jens]

Hat sich jemand schon mal http://www.sqlalchemy.org ORM angesehen??? Sieht auf den ersten Blick ganz nett aus, weil man doch recht nah an den original SQL-Statements ist...

[Leonidas]

Noch ein ORM! Was bringt uns dann, außer einer neuen Syntax?

Da hätte ich noch Dejavu einzuwerfen, und auch noch Jeff Watkins Fusion aus Hibernate und CoreData.

[jens]

Vielleicht sollte man mal eine Liste erstellen und schauen, welches wirklich das beste ist.

Bei sqlalchemy ist mir direkt die ausfühliche Doku aufgefallen. Das ist gleich ein dicker Pluspunkt...

Beim überfliegen der Doku ist mir aufgefallen, das man relativ nah an der SQL-"Abfragetechnik" ist, nicht so wie bei SQLObjekt...

[Leonidas]

Aber ich will doch ein ORM um mit Objekten nicht zu arbeiten, nicht mit etwas SQL ähnlichem. Dann kann ich auch gleich SQL nehmen.

[jens]

Mir geht es auch eigentlich auch nicht darum ein ORM zu nehmen. Ich glaube das sqlalchemy auch nicht wirklich.
Ich möchte nur einen Layer zwischen der Datenbank und meinem Programm haben. Nicht aber auch niedrigen Ebene, wie das Python-DB-API, sondern auf SQL-Befehls-Ebene... Also das ich verschiedene SQL-Server mit ein und der selben Schnittstelle ansprechen kann...

z.B. ist mir SQLObjekt ein zu weites Stück vom DB-Server entfernt... Für kleinere Aufgaben ist es vielleicht ganz nett (Wobei dann könnte man auch gleich ZOBD nehmen)...

Ich werde aber wahrscheinlich meinen SQL-Wrapper mit blackbirds Datenbank-Modul paaren und dann hab ich was ich will

Wobei eigentlich Wrapper, die für verschiedene DBs gleichzeitig sind, immer einen Nachteil haben. Sie müßen sich auf den kleinsten gemeinsammen Nenner einigen... Somit kann man logischerweise keine Speziellen Features von den einzelnen DBs nutzten... (Aber das übersteigt eh mein Wissen um SQL )

[Leonidas]

z.B. ist mir SQLObjekt ein zu weites Stück vom DB-Server entfernt... Für kleinere Aufgaben ist es vielleicht ganz nett (Wobei dann könnte man auch gleich ZOBD nehmen)...

Schwer, da man ZODB Datenbanken nur mit Python lesen kann.

Wobei eigentlich Wrapper, die für verschiedene DBs gleichzeitig sind, immer einen Nachteil haben. Sie müßen sich auf den kleinsten gemeinsammen Nenner einigen... Somit kann man logischerweise keine Speziellen Features von den einzelnen DBs nutzten... (Aber das übersteigt eh mein Wissen um SQL )

Da hat SQLObject den Vorteil, dass es spezielle Features nutzen kann, wo es nötig/möglich ist.