Charles V. wrote:
It's at least incomplete. fetchone() and fetchmany() won't work any longer.
-- Gerhard
Hi,
>
>
You are right: the default Cursor in MySQLdb fetches the complete set on the
client (It explains why I have a "correct" answer with MySQLdb). As having
multiple cursor isn't an option for me and using non-standard execute on the
connection neither, I tried to modify the Cursor class to store results on
the client side.
>
----------------
class NewCursor(sqlit e3.Cursor):
def __iter__(self):
return iter(self.fetch all())
>
conn = sqlite3.connect (':memory:')
[...[]
>
>Both may be standard compliant, but if you're depending on
>implementati on details, you may still get different behaviour.
>I'm pretty sure that MySQLdb always fetches the entire resultset from
>the server. The sqlite3 module uses what would have been called
>"server-side cursors" in real databases, i. e. it only fetches rows on
>demand. To fetch everything in one go with the sqlite3 module, you have
>to call fetchall() explicitly.
>implementati on details, you may still get different behaviour.
>I'm pretty sure that MySQLdb always fetches the entire resultset from
>the server. The sqlite3 module uses what would have been called
>"server-side cursors" in real databases, i. e. it only fetches rows on
>demand. To fetch everything in one go with the sqlite3 module, you have
>to call fetchall() explicitly.
You are right: the default Cursor in MySQLdb fetches the complete set on the
client (It explains why I have a "correct" answer with MySQLdb). As having
multiple cursor isn't an option for me and using non-standard execute on the
connection neither, I tried to modify the Cursor class to store results on
the client side.
>
----------------
class NewCursor(sqlit e3.Cursor):
def __iter__(self):
return iter(self.fetch all())
>
conn = sqlite3.connect (':memory:')
[...[]
Do you think it is a good solution (any drawbacks ?) ?
-- Gerhard