On 03/27/2013 10:53 AM, Stefano Crosta wrote:
Thanks Aymeric,
that's true, and I should have put that link too.
sadly "akaariai" who's the only one who seemed to understand a bit
about it (and is a core dev) did not seem interested in bringing this
any forward, so I thought I'd try to raise some interest again!
The problem is that server side cursors will need dedicated API, and
there will be database specific problems when using server side cursors.
On SQLite changes done to rows are visible in the results, on other
databases not. On PostgreSQL you will need to use WITH HOLD cursors if
you want to use server side cursors outside transactions (that is, in
autocommit mode normal server side cursors do not work). When using WITH
HOLD cursors you must close the cursor explicitly or you will have
cursor leak... And on MySQL WITH HOLD cursors aren't available at all,
so you must be in transaction to use server side cursors.
Oracle seems to be the only core DB that will work without problems. In
fact, using .iterator() on Oracle already works without memory problems.
Maybe the dedicated API could be adding two new keywords to .iterator():
server_side_cursor, and with_hold. with_hold=True implies
server_side_cursor=True. If you use with_hold=True you are responsible
for closing the iterator, too. The behaviour of server_side_cursor and
with_hold is database specific - it will be impossible to abstract the
differences away.
- Anssi
--
You received this message because you are subscribed to the Google Groups "Django
developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
