On Tuesday 04 September 2012, Ian Kelly wrote: > On Mon, Sep 3, 2012 at 6:14 AM, Shai Berger <s...@platonix.com> wrote: > > On Wednesday 29 August 2012 22:17:22 Ian Kelly wrote: > >> https://github.com/ikelly/django/commit/086f502a1c2acb9db27531f7df78cb9d > >> f9a b83bd > > > > more subtle; either way, this is what I got from a page which makes > > several hundred queries (don't ask): > > Are these ORM queries or custom queries?
Mostly ORM. > If the latter, are you > explicitly closing the cursors? That should help prevent the issue, > although unfortunately the ORM doesn't do this. The cursors should be > closed anyway when they're finalized, but maybe we've got a reference > cycle preventing them from getting cleaned up right away, and too many > are accumulating between garbage collection passes. > That would make sense. > When I've seen this error in the past, the immediate solution has been > to increase the OPEN_CURSORS parameter in the database. See: > > http://www.orafaq.com/wiki/ORA-01000 > I'll try, but this shouldn't be the long-term solution -- especially not when an alternative exists, which does not have this problem. BTW, I'm not at all sure that using outputtypehandler (function called per returned value) is more efficient than using rowfactory (function called per row) when both are used via the cx_oracle API. The current code calls its _rowfactory outside this API, which does seem inferior. If the rowfactory approach behaves better in terms of GC, I don't see why we should insist on outputtypehandler. I'll try to prepare a patch for consideration, hopefully this week. Thanks, Shai. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
