Erfahrungsberichte: ADOdb auf Python

[droptix]

Hat jemand schon Erfahrungen mit ADOdb auf Python-Basis gemacht? Es wurde ja ursprünglich für PHP entwickelt und auf Python ausgeweitet. Daher soll es nicht sooo gut wie die Version für PHP sein. Ein Mythos oder Wirklichkeit?

Würde ADOdb zukünftig gerne einsetzen, um Programme etwas unabhängiger von der verwendeten Datenbank zu machen, würde aber vorher gern ein paar Erfahrungsberichte hören. Danke!

[jens]

hättest du einfach mal im Forum gesucht, würdest du auf http://www.python-forum.de/viewtopic.php?t=2039 gestoßen sein

[droptix]

Hi jens, Beispiele findet man viele im Netz. Die Frage war: Ist ADOdb für Python wirklich "schlechter" als die PHP-Variante? Oder kann man ADOdb für Python bedenkenlos auch in größeren Projekten verwenden?

[Joghurt]

Ist ADOdb für Python wirklich "schlechter" als die PHP-Variante?

Wer hat das behauptet?

Ich wüsste nicht, wieso ein PHP-Modul besser sein sollte als das entsprechende Pythonmodul.

[droptix]

Wil es auf Python portiert wurde und deshalb eigentlich nicht nativ drauf ausgerichtet ist. Außerdem hat PHP für viele Datenbanken bereits eigene Standard-Befehle, die ADOdb einfach vereinheitlicht.

Bei Python gibt es meistens verschiedene Wrapper für die Datenbanken. Manchmal gibt es sogar mehrere... und sie müssen als Modul eingebunden werden, was eben Abhängigkeiten erzeugt. Ist bei PHP alles nicht der Fall. Deshalb die Frage.

[Leonidas]

Bei Python gibt es meistens verschiedene Wrapper für die Datenbanken. Manchmal gibt es sogar mehrere...

Die sich wiederrum meist an die DB-API2 halten.

[tabellar]

Wil es auf Python portiert wurde und deshalb eigentlich nicht nativ drauf ausgerichtet ist. Außerdem hat PHP für viele Datenbanken bereits eigene Standard-Befehle, die ADOdb einfach vereinheitlicht.

Bei Python gibt es meistens verschiedene Wrapper für die Datenbanken. Manchmal gibt es sogar mehrere... und sie müssen als Modul eingebunden werden, was eben Abhängigkeiten erzeugt. Ist bei PHP alles nicht der Fall. Deshalb die Frage.

Hi droptix,

ich glaub, Du musst Dir das mit den Datenbanken nochmals genau anschauen . Ich hab ein bisschen bei ADOdb geschmökert und es sieht ja bei PHP so aus, dass es dort keinen einheitlichen Standard zum ansprechen von DBs gibt. Dieses Manko will ja ADOdb gerade schliessen, indem es als Abstraktionslayer für DBs fungiert.

Python hingegen besitzt den DB-API Specification 2.0 Standard, den die meisten DB API Module unterstützen. Sprich, wenn Du Dich an die DB API 2.0 hälst, bist Du auf der sicheren Seite. Es gibt auch interessante native Python DBs (kein Modul notwendig), die für viele Zwecke locker ausreichen. Man braucht nicht immer gleich einen DB Server, der auch entsprechend konfiguriert und gewartet werden muss.

Ich glaub, Dir geht's eher darum, PHP oder Python ...

Tabellar

[droptix]

Nee, wenn schon dann Python Nur wenn ich ADOdb einsetzen will, muss es auch stabil sein und alles unterstützen, was es promotet... Kann ja schlecht was entwickeln und sagen: "Wir unterstützen alle gängigen Datenbanken..." und dann ist ADOdb wirklich noch einen Schritt hinter der PHP-Version zurück und meine Angaben sind damit nicht ganz korrekt. Erklär das dann mal einem Kunden

Ich meinte, dass bei PHP bereits alle Funktionen zum Arbeiten mit Datenbanken im PHP-Quellcode enthalten sind. Also einmal PHP installiert und man hat sofort (ohne zusätzliche Module) Befehle für den Zugriff auf verschiedene Datenbanken. Aber Recht hast du: die sind aus der Historie einfach nicht einheitlich. Deswegen ja ADOdb...

Aber OK, wenn sich die Python-Module an den DB-API Specification 2.0 Standard halten, sollte es ja keine Probleme geben. Es ist für mich manchmal ungewöhnlich, dass es z.B. mehrere Wrapper für SQLite gibt... warum? Lieber sollen alle Entwickler an einem Strang ziehen und nur ein Modul bauen. Aber hab schon gesehen, dass bei solchen Fällen in ADOdb dann auch genau drin steht, welches Modul vorausgesetzt wird.

[Leonidas]

Aber OK, wenn sich die Python-Module an den DB-API Specification 2.0 Standard halten, sollte es ja keine Probleme geben. Es ist für mich manchmal ungewöhnlich, dass es z.B. mehrere Wrapper für SQLite gibt... warum?

Es gibt nur einen wirklich guten (den 99% aller Leute die sowas brauchen nutzen), PySQLite der dafür sehr gut ist. Das was auf SqliteWrappers steht sind meist ORMs, die von PySQLite abhängen. Dabei laufen alle DB-Operationen über PySQLite.

[droptix]

Aha, dachte ich mir's doch. Wie man hier lesen kann, vereinheitlicht ADOdb auch die Unterschiede bei der SQL-Syntax verschiedener Datenbank-Sprachen. Es macht also doch Sinn, ADOdb einzusetzen, wenn es nur um Standard-Abfragen wie SELECTs, INSERTs oder UPDATEs geht. Hier der vielleicht wichtigste Auszug:

You might ask why Python needs a database abstraction library when Python provides the official DB API. Unfortunately the DB API does not encapsulate differences in the database implementations. For example, to select a limited number of rows, say 10 rows, you would have to use very different SQL for different databases:

MS SQL: select top 10 from table
MySQL and PostgreSQL: select * from table limit 10
Oracle: select * from (select * from table) where rownum <= 10

These differences are handled by ADOdb (using SelectLimit), but not by the Python DB API. Other important database differences transparently handled by ADOdb include date-formating, associative arrays (records as dictionaries) and LOB-handling.

Das ist doch eigentlich sehr wichtig, wenn man eine DB-unabhängige Anwendung programmieren will, oder? Ich hab sowas Ähnliches wie ADOdb mit PHP auch schon für MySQL gemacht... ein SQL-SELECT-statment sieht dann z.B. nur noch so aus:

Code: Alles auswählen

// automatisch nur MySQL, könnte aber erweitert werden
$db = new Database();
$db->connect();
$tables_fields = array (
    'table1' => array ('primaryKeyField', 'otherField1', 'otherField2 AS aliasField2'),
    'table2' => array ('primaryKeyField', 'otherField')
);
$where = "primaryKeyField = 123";
// $limit, $autocloseConnection und weitere Argumente könnten übergeben werden
$result = $db->Select($tables_fields, $where);
$db->close();
print_r ($result);
// würde bringen:
// $result['pk'] = array (123) // alle Primary Keys
// $result['set'][123] = array (...die Werte der Felder...)
// $result['1st'] = array (... die erste Zeile, die ausgelesen wurde ...) 

Und sowas hab ich auch für Python gesucht. Meint ihr immernoch, dass das für Python keinen Sinn macht und die DB-Wrapper ausreichen? Falls ja, wieso? Ich persönlich finde ADOdb sehr sinnvoll...

[Leonidas]

Meint ihr immernoch, dass das für Python keinen Sinn macht und die DB-Wrapper ausreichen? Falls ja, wieso? Ich persönlich finde ADOdb sehr sinnvoll...

Dann nimm ADOdb, wenn du damit glücklich wirst. Ich würde es nicht nehmen, weil:

• another Abstraction Layer
• es bügelt die Unterschiede aus, aber nur teilweise, für kompliziertere Sachen muss man ja dann doch DB-spezifisches SQL schreiben.
• die API gefällt mir nicht:

  Code: Alles auswählen

  while not cursor.EOF:
  print cursor.fields
  cursor.MoveNext()

  EOF? Wofür gibts in Python Iteratoren?

Wenn dann würde ich mir einen ORM wie SQLAlchemy, SQLObject oder auch Dejavu.