|
Size: 940
Comment:
|
← Revision 4 as of 2008-11-15 13:59:41 ⇥
Size: 1336
Comment: converted to 1.6 markup
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 5: | Line 5: |
| A cursor is a set of database rows you iterate over. It can be clientside or server-side. | A cursor is a set of database rows you iterate over. It can be clientside or server-side. |
| Line 7: | Line 8: |
| In the DbApi, you first create a cursor object, then execute a statement on it, then fetch the results. | In the DbApi, you first create a cursor object, then execute a statement on it, then fetch the results. |
| Line 9: | Line 11: |
| The normal way of using cursors with the DB-API is to reuse the cursor objects and fire new statements with them, and fetch new results. | The normal way of using cursors with the DB-API is to reuse the cursor objects and fire new statements with them, and fetch new results. |
| Line 15: | Line 18: |
| {{{ | |
| Line 22: | Line 26: |
| }}} | |
| Line 25: | Line 30: |
| executing statements logically belongs in the connection object, not in the cursor object. | executing statements logically belongs in the connection object, not in the cursor object. |
| Line 27: | Line 33: |
| Enough ranting for now, more will come some day. Maybe somebody can clean this up and add a few thoughts :) | (Alas, then you could only loop over a single set of results at a time. I think the current cursor concept makes sense. -skip) |
| Line 29: | Line 36: |
| Enough ranting for now, more will come some day. Maybe somebody can clean this up and add a few thoughts :) --- The "execute" method, or whatever it's called, could then return an iterator. In that case there is no problem with loop over different sets of results. The current cursor concept does make *some* sense, but it's awkward and pre-iterators. |
What sucks about the DbApi
It totally misuses the cursor concept.
A cursor is a set of database rows you iterate over. It can be clientside or server-side.
In the DbApi, you first create a cursor object, then execute a statement on it, then fetch the results.
The normal way of using cursors with the DB-API is to reuse the cursor objects and fire new statements with them, and fetch new results.
This is totally misguided in my opinion.
A much better API should look similar to:
cx = dbapimodule.connect()
cx.execute("insert into tablename(val) values (?)", ('foo',))
for row in cx.executeReader("select val from tablename"):
print row
row = cx.executeRow("select max(val) from tablename")etc.
executing statements logically belongs in the connection object, not in the cursor object.
(Alas, then you could only loop over a single set of results at a time. I think the current cursor concept makes sense. -skip)
Enough ranting for now, more will come some day. Maybe somebody can clean this up and add a few thoughts 
---
The "execute" method, or whatever it's called, could then return an iterator. In that case there is no problem with loop over different sets of results. The current cursor concept does make *some* sense, but it's awkward and pre-iterators.