From: <yu...@ad...> - 2003-10-27 10:10:38
|
Quoting ??? <yo...@li...>: > Hi~ > > Python DB2 module owes a lot to Yuval. > I think he should have write access to PyDB2 CVS in sf.net. Cool - thanks! > You mean the line number 414 in _db2_module.c? > I didn't know about the memory consumption in case of no autocommit. > But "No" auto commit is the default mode the most people expect. > They don't want they INSERT or UPDATE operation committed > immediately. But this affects the SELECT queries as well - I mean if you don't call commit after your SELECT statements, the module keeps consuming memory without bounds. I dont know about other ppl, but as a user of this module it seems silly that i have to commit after SELECT. For now, I just set autocommit(1) after creation and it solves the problem. > I didn't find the clean way to avoid cyclic reference situation. > In case of db.close(), users expect cursors from that ``db'' also close, > I think. How about your idea? I didn't think of that - but for this case, I think I read somewhere that there's an object type that is allowed to have cyclic ref. in it. --- Python C API --- TYPE* PyObject_GC_New( TYPE, PyTypeObject *type) Analogous to PyObject_New() but for container objects with the Py_TPFLAGS_HAVE_GC flag set. --------------------- And GC can handle the situation you mentioned (I think... :-) ) Another solution would be to remove the db.close method... ;-) Btw, regarding the fetching functions - why don't we use the DB2_cursor_object_fetchall and fetchmany functions ? In DB2.py there's a loop in fetchall and fetchmany that calls self.fetchone(). Is there a special reason for not using the C functions ? Thanks, Yuval. ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/ |