Re: [PyDB2-discuss] Re: Db2 module issues.

[<yu...@ad...>]

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/