MySQLdb, wpl.db oder alternativen, brauche Tipps

[würmchen]

Hi Leute,

ich hab ein Buch "Web Programming in Python" an das ich mich im Moment halte um meine Website aufzubauen. Ich bin gerade auf die MySQL anbindung gestoßen und die empfehlen das Modul wpl.db
Ich finde es aus dem Grund interessant, weil ich dann die Datenbank Informationen in einem separaten File aufbewahren kann und nicht direkt im Quellcode. Leider sagen die nur, das die Daten in einem Configfile liegen sollen und nicht wie dieses File heißt.
Also hab ich mich auf die Suche gemacht und festgestellt, das ich zu diesem Modul fast nichts finden kann.
Entweder wird da nicht mehr entwickelt oder ich stell mich nur zu doof an...

Würde mich freuen von ein paar Erfahrenen Leuten Tipps zu bekommen, welche Module sich anbieten.

Grüße Wurm

[keppla]

Würde mich freuen von ein paar Erfahrenen Leuten Tipps zu bekommen, welche Module sich anbieten.

Keine Ahnung, ob es in dem bereich liegst, den du suchst (ich kenne wpl nicht, und google gibt als ersten treffer dein post ), aber ich bin recht glücklich mit sqlalchemy.
SQLAlchemy ist ziemlich weit weg von purem SQL, und bietet einige recht coole Dinge, die im "Ruby on Rails"-Hype modern geworden sind (ActiveRows, Tabellendefinitionen in einer "Domain Specific Language").

[Leonidas]

Tabellendefinitionen in einer "Domain Specific Language"

Wo bietet denn SQLAlchemy das? Elixir tuts, aber in SQLAlchemy ist das meines Wissens nicht so.

[keppla]

Tabellendefinitionen in einer "Domain Specific Language"

Wo bietet denn SQLAlchemy das? Elixir tuts, aber in SQLAlchemy ist das meines Wissens nicht so.

In sqlalchemy sieht eine Tabellendefinition z.B. so aus:

Code: Alles auswählen

imageversion_table = Table('imageversion', metadata,
    Column('id', Integer, primary_key=True),
    Column('name', String(50, convert_unicode=True), nullable=False),
    Column('image_id', Integer, ForeignKey('image.id'), nullable=False),
    Column('width', Integer, nullable=False),
)

vermutlich variiert meine definition von DSL stark von deiner.

[Y0Gi]

Meine Definition einer DSL trifft auch nur auf Elixir zu, aber nicht auf SQLAlchemy oder SQLObject.

würmchen: Was heißt in diesem Fall "Datenbank-Informationen"? Die Zugangsdaten? Die kannst du auch so in einer separaten Datei aufbewahren, unabhängig vom verwendeten Adapter-Paket.

[keppla]

Meine Definition einer DSL trifft auch nur auf Elixir zu, aber nicht auf SQLAlchemy oder SQLObject.

Ohne den Thread hijacken zu wollen: hast du zu deiner definition was lesbares? Meine ist recht Vage und läuft auf "Sprachmittel so gebrauchen, dass es deklarativ aussieht" hinhaus.

[Y0Gi]

Nö. Ich habe jedoch im Zusammenhang mit Elixir von einer DSL gelesen, bei den anderen nicht.

Laut Wikipedia wird eine DSL beschrieben als

Eine domänenspezifische Programmiersprache (engl. domain-specific language, DSL) ist eine formale Sprache, die speziell für ein bestimmtes Problemfeld (die Domäne) entworfen und implementiert wird.

Wenn (z.B.) eine ORM-Deklaration also reines Python mit eigenen Objekten ist, dann ist das für mich keine DSL.

Elixirs DSL-Syntax (die dort auch so überschrieben wird) ist zwar selbst auch in Python implementiert, aber irgendwie abstrakter. Zwar sind es mehr oder weniger nur Funktionsaufrufe, doch operieren sie auf Daten im Hintergrund (es wird nichts zurückgegeben). Auch die Benennung ist irgendwie semantisch anders, die Aufrufe werden wie Definitionen, nicht Aktionsanstöße verwendet.
An dieser Stelle sind meine Kompetenzen zu formalen Sprachen, Sprachdesign und dergleichen allerdings erschöpft und ich bitte auch, mir die unfachgemäße Formulierung nachzusehen

[Leonidas]

vermutlich variiert meine definition von DSL stark von deiner.

Das würde ich auch sagen. Denn für mich ist dass nur eine Objektinstanziierung mit ein paar zusätzlichen Zeilenumbrüchen. Das ist definitiv weniger magisch, als das was Elixir oder Django machen, indem sie mit Metaklassen die Felder bearbeiten.

Für mich sind DSL eben etwas magischer als banale Zeilenumbrüche. Oder meinst du den Semantischen Wert von ``Table``, der besagt dass das eine Tabelle ist. Das überzeugt mich auch nicht, denn dann würde jede Lib ihre eigene DSL sein, weil sie eine eigene API bietet, die eben Domain Specific ist (was auch sonst).

[keppla]

An dieser Stelle sind meine Kompetenzen zu formalen Sprachen, Sprachdesign und dergleichen allerdings erschöpft und ich bitte auch, mir die unfachgemäße Formulierung nachzusehen

Ich wäre mit meiner unglaublich wissenschaftlichen Definition kaum in der Position klugzuscheissen

Laut Wikipedia wird eine DSL beschrieben als

Eine domänenspezifische Programmiersprache (engl. domain-specific language, DSL) ist eine formale Sprache, die speziell für ein bestimmtes Problemfeld (die Domäne) entworfen und implementiert wird.

Wenn (z.B.) eine ORM-Deklaration also reines Python mit eigenen Objekten ist, dann ist das für mich keine DSL.

Wikis definition kenne ich auch, aber irgendwie scheinen der wenige zu folgen. Dinge wie PyParse habe ich auch schon als DSL-nutzend beschreiben gesehen. Irgendwie schient mir DSL eher in richtung "kreativer (miss|ge)brauch der Sprache" zu gehen.

Auch die Benennung ist irgendwie semantisch anders, die Aufrufe werden wie Definitionen, nicht Aktionsanstöße verwendet.

Deshalb meinte ich das bei SQLAlchemy: die Tabellen sehen für mich auch eher nach definitionen aus.

Und um daraus mal die überleitung zum Ursprungspost herzustellen:
Das ist der Teil, den ich an SQLAlchemy mag. Ich fand es immer unglaublich lästig, den Übergang von "Objekten in der Applikation" zu "Zeilen in Tabellen in der DB" selber zu schreiben.
Mit SQLAlchemy hab ich einen Ort, an dem dieser Übergang beschrieben ist (also ein modul, in dem Tabellen und Objektklassen definiert sind), und damit ists dann auch erledigt. Die Installation der DB kann daraus erfolgen, das erstellen, holen und ändern der Objekte, teilweise kann man es nutzen, um direkt daraus Formulare zu erstellen (á la Django).
Pures SQL finde ich mittlerweile eher lästig.

[würmchen]

Ich hab mich in ein Tutorial eingelesen und denke das ist etwas für mich. Mit den Zugangsdaten der Datenbanken auslagern werd ich dann denke ich händig machen, hab jetzt in SQLalchemy nichts wirklich darüber gefunden. aber es macht nen viel übersichtlicheren Eindruck die Befehle in der pythonsyntax zu schreiben.

[keppla]

Mit den Zugangsdaten der Datenbanken auslagern werd ich dann denke ich händig machen, hab jetzt in SQLalchemy nichts wirklich darüber gefunden.

Das ist eher implizit erwähnt: http://www.sqlalchemy.org/docs/04/metad ... es_binding

Du baust die Verbindung über eine db-url auf, die in etwa so aussieht:

mysql://username:password@server:port/database

wo die herkommt, ist dem Code ziemlich egal, da es nur ein String ist, Man könnte ihn aus den Kommandozeilenargumenten, aus eine Userabfrage, aus einer Datei etc holen.

[Y0Gi]

In dem Zusammenhang ist auch `engine_from_config()` interessant, das (gepräfixte) Werte aus einem Dictionary lesen kann, das nicht selten aus einer (z.B. `.ini`-artigen) Konfigurationsdatei extrahiert wird (im Falle von Webanwendungen ist da PasteDeploy recht verbreitet).

[würmchen]

Hi, also ich bin gerade dabei meine Datenbank mit Hilfe von SQLAlchemy abzufragen und stoße dabei auf ein Problem. Vielleicht ist es auch ein Denkfehler?!?


Hier mal ein wenig code:

Code: Alles auswählen

#!/usr/bin/python

from sqlalchemy import *

class Query(object):
    def __init__(self):
        self.teststring = "Ein teststring um zu schaun ob ich die Variablen ausgeben kann"
        db = create_engine('mysql://localhost/bif_1107', echo=True)
        metadata = BoundMetaData(db)
        conn = db.connect()
        

class PdbKey(Query):
    def __init__(self, value = ""):
        Query.__init__(self)
        print self.teststring

    def doEvaluation(self):
        s = select([MMS_ENTRY])
        result = conn.execute(s)


def main():
    test = PdbKey("test")
    test.doEvaluation();

if __name__ == '__main__':
    main()

Ich habe eine vorhandene Datenbank namens bif_1107 und in dieser befindet sich eine Tabelle namen MMS_ENTRY, aus der will ich lesen.

Leider beschwert er sich das bei "s = select([MMS_ENTRY])" die Variable MMS_ENTRY nicht bekannt sei...

Ich denke mir das ich ein Fehler mache und die Datenbank nicht einlese... Aber irgendwie konnte ich das im Tutorial nicht finden. Ich finde nur wie ich einzelne Tabellen neu einlesen kann.

Kann mir jemand meinen Fehler nennen?

[Leonidas]

Ich denke mir das ich ein Fehler mache und die Datenbank nicht einlese... Aber irgendwie konnte ich das im Tutorial nicht finden. Ich finde nur wie ich einzelne Tabellen neu einlesen kann.

Du liest mit SQLAlchemy auch keine Datenbanken ein, sondern Tabellen. Du definierst die Tabellenrelationen und mappst sie dann mit dem OR-Mapper von SQLAlchemy an Klassen.

Achja, und gewöhn dir dringend Stern-Imports ab. Besser jetzt als später.

[würmchen]

Ich denke mir das ich ein Fehler mache und die Datenbank nicht einlese... Aber irgendwie konnte ich das im Tutorial nicht finden. Ich finde nur wie ich einzelne Tabellen neu einlesen kann.

Du liest mit SQLAlchemy auch keine Datenbanken ein, sondern Tabellen. Du definierst die Tabellenrelationen und mappst sie dann mit dem OR-Mapper von SQLAlchemy an Klassen.

Achja, und gewöhn dir dringend Stern-Imports ab. Besser jetzt als später.

Ok, ich hab dann eben auch mein denkfehler gefunden, hab vergessen diese tabellenrelation zu erstellen und mal wieder die ganzen self's wo sie hingehören....

was ist denn empfehlenswerter als die * imports? Ich halt mich halt immer, oder versuch es weitgehenst, an die tutorials zu halten