Seite 1 von 1

wozu ist der sql cursor da?

Verfasst: Donnerstag 12. Juli 2007, 16:25
von Costi
ich steig grad von SQLobject auf "raw SQL" um.
und hab nicht ganz verstanden wofuer ein cursor noetig ist
kann ich nicht einfach ein einzigen cursor fuer die gesamte web app benuzten?

klaert mich auf :D :D :D

Re: wozu ist der sql cursor da?

Verfasst: Donnerstag 12. Juli 2007, 16:33
von Leonidas
Costi hat geschrieben:kann ich nicht einfach ein einzigen cursor fuer die gesamte web app benuzten?
Ja, das geht.

Verfasst: Donnerstag 12. Juli 2007, 16:55
von BlackJack
So ganz uneingeschränkt würde ich nicht ja sagen. Das geht nur, wenn man über diesen Cursor immer eine Anfrage nach der anderen macht, also weder Threads benutzt, noch während man über das Ergebnis einer Anfrage iteriert, weitere Anfragen stellen möchte.

Re: wozu ist der sql cursor da?

Verfasst: Donnerstag 12. Juli 2007, 16:57
von jens
Costi hat geschrieben:ich steig grad von SQLobject auf "raw SQL" um.
Gibt es dafür einen speziellen Grund?
Warum nicht von SQLobject nach SQLAlchemy wechseln???

Re: wozu ist der sql cursor da?

Verfasst: Donnerstag 12. Juli 2007, 17:09
von gerold
Hallo Costi!
Costi hat geschrieben:ich steig grad von SQLobject auf "raw SQL" um.
Gute Wahl. :-) Ist, in meinen Augen, sowiso viel einfacher als dieses gesülze mit diesen OR-Mappern.
Costi hat geschrieben:klaert mich auf :D
In wenigen Sätzen? Gar nicht mal so einfach. Ich versuche es trotzdem mal.

Die Daten in einer "Relationalen Datenbank" (das sind die Datenbanken die wir allgemein so kennen und die mit SQL abgefragt werden können) werden in Tabellen mit Feldern (Spalten) und Datensätzen (Zeilen) verwaltet.

Wenn man mit einer SELECT-Anweisung Daten von der Datenbank verlangt, dann bekommt man diese Daten ebenfalls wieder in einer Tabellen-Struktur (als Recordset oder Dataset) zurück. Wenn dabei sofort alle Daten von der Datenbank zum Client-Programm übertragen werden, dann spricht man von "client side". Und wenn die Daten einer Ergebniszeile (=Datensatz) erst dann vom Server zum Client übertragen werden wenn diese Zeile abgefragt wird, dann spricht man von "server side". Die Python-DB2-API überlässt der Datenbankschnittstelle (pySQLite, pyODBC, psycopg2, usw.), ob die Daten sofort zum Client übertragen werden, oder nicht.

Der Cursor ist, in relationalen Datenbanken, der Zeiger, der auf die aktuelle Zeile eines Recordsets (=Ergebnis-Tabellenstruktur) zeigt.

Wenn du also z.B. mit ``cur.execute("SELECT * FROM adressen")`` alle Adressen von der Datenbank verlangst, dann zeigt ``cur`` nach dieser Anweisung auf die erste Zeile des Ergebnisses. Dieses Zeigerobjekt wurde also in Python "Cursor" genannt, weil es in etwa dem "Cursor" der Datenbank entspricht. Natürlich ist der Cursor nicht direkt der Zeiger auf die aktuelle Datenzeile, sondern ein abstraktes Python-Objekt, das als Zwischenschicht zwischen dem richtigen Cursor der Datenbank und unsererer Anwendung dient.
Wenn du mit ``cur.fetchone()`` die Daten der aktuellen Zeile abfragst, dann liefert dir der Cursor die Daten und springt gleichtzeitig zur nächsten Zeile.

Ob du einen Cursor immer wieder verwenden kannst, hängt direkt mit der verwendeten Datenbankschnittstelle (pySQLite, pyODBC, psycopg2, usw.) und mit den damit gemachten Transaktionen zusammen. Wenn du auf Nummer Sicher gehen willst, dann erstelle für jede neue SQL-Anweisung auch einen neuen Cursor. Das kann nicht schaden und macht kaum Umstände.

Ich würde also nicht den Cursor zentral zur Verfügung stellen, sondern nur die Connection.

Code: Alles auswählen

conn = ...
...
cur = conn.cursor()
cur.execute("SELECT ...")
for row in cur:
    print list(row)
cur.close()
...
cur = conn.cursor()
cur.execute("SELECT ...")
for row in cur:
    print list(row)
cur.close()
mfg
Gerold
:-)

PS: In wenigen Sätzen? Ist mir wohl nicht geglückt. ;-)

Verfasst: Donnerstag 12. Juli 2007, 17:11
von jens
Ab in's Wiki damit *vote*

.oO(Ich weiß manche Leute mögen das Wiki nicht)