3 ms·
I think OP has a point. He's not complaining about the functionality (of course a DB client needs to iterate through results) but that there's no reason a user
by luhn 7y ago
I think OP has a point. He's not complaining about the functionality (of course a DB client needs to iterate through results) but that there's no reason a user needs to understand cursors for running simple DB queries. I should be able to do:
results = conn.execute("select * from mytable").fetchall()
or
query = conn.execute("select * from mytable")
for row in query:
print(row.id)
You can do the same with cursors, but it's extra mental overhead and a somewhat awkward API.
Plus the name conflicts with Postgres' CURSOR, which confused me when I first started. So, yes, I would prefer "iterator" :)
- quietbritishjim 7y agoYou are right and I had forgotten about that. I mostly use SQLite from Python which actually does allow .execute() on the connection as a non-standard extension to DBAPI, so it supports exactly the two snippets you posted. It is a bit awkward that you have to create your cursor before you execute the query, I don't quite see the reason for that.
- skeletal88 7y agoYes, that's what I meant, it doesn't have to be exposed to the user, I just want to execute a query and get the results. If needed then maybe I should be able to create a cursor to go through the results. It's just that other database access APIs don't expose and force the developers using the API to use a cursor, so it's mildly annoying in Python.