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
wozu ist der sql cursor da?
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.
- gerold
- Python-Forum Veteran
- Beiträge: 5555
- Registriert: Samstag 28. Februar 2004, 22:04
- Wohnort: Oberhofen im Inntal (Tirol)
- Kontaktdaten:
Hallo Costi!
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.
mfg
Gerold
PS: In wenigen Sätzen? Ist mir wohl nicht geglückt.
Gute Wahl. Ist, in meinen Augen, sowiso viel einfacher als dieses gesülze mit diesen OR-Mappern.Costi hat geschrieben:ich steig grad von SQLobject auf "raw SQL" um.
In wenigen Sätzen? Gar nicht mal so einfach. Ich versuche es trotzdem mal.Costi hat geschrieben:klaert mich auf
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()
Gerold
PS: In wenigen Sätzen? Ist mir wohl nicht geglückt.
Zuletzt geändert von gerold am Donnerstag 12. Juli 2007, 17:20, insgesamt 2-mal geändert.
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.