python-sybase-misc

[python-sybase] Sybase module 0.37pre1 released

[Dave C. <dj...@ob...>]

WHAT IS IT:

The Sybase module provides a Python interface to the Sybase relational
database system.  It supports all of the Python Database API, version
2.0 with extensions.

NOTES:

This release contains a number of small bugfixes and patches received
from users.

I have been unable to find the source of the memory leak reported here:
 
http://www.object-craft.com.au/pipermail/python-sybase/2004-December/000346.html

The test program I wrote follows:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
import sys
import Sybase

db = Sybase.connect(..., auto_commit=True)
db.execute('''
if exists (select name from sysobjects where name = "sp_test_leak")
begin
     drop procedure sp_test_leak
end
''')
db.execute('''
create procedure sp_test_leak
     @arg int
as
     select @arg
''')
for i in range(200):
     for j in range(1000):
         c = db.cursor()
         c.callproc('sp_test_leak', {'@arg': 12345 })
     sys.stdout.write('%3d\r' % i)
     sys.stdout.flush()
sys.stdout.write('\n')
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

If someone is able to modify this and come up with a leaking result I
am interested in working on the fix.

You can build for FreeTDS like this:

      python setup.py build_ext -D HAVE_FREETDS -U WANT_BULKCOPY
      python setup.py install


The module is available here:

 
http://www.object-craft.com.au/projects/sybase/download/sybase-0.37pre1.tar.gz

The module home page is here:

     http://www.object-craft.com.au/projects/sybase/

CHANGES SINCE 0.36:

* Cursor output parameters now work when parameters are passed as a
   sequence.

* Output parameters now work for FreeTDS 0.62.4.

     1> create procedure sp_test_output
     2>     @num int, @result int output
     3> as
     4>     select @result = @num
     5> go

     params = c.callproc('sp_test_output', {'@num': 12345,
                                            '@result': Sybase.OUTPUT(1)})
     print params['@result']

* The CS_STATUS_RESULT result set is now consumed internally in the
   Cursor and does not appear in the result sets consumed by the fetch
   and nextset methods.

   The return value from the stored procedure is available in the
   .return_status member of the Cursor.  It will only contain a
   meaningful value once all of the row result sets have been consumed.

   Note that this does not work with FreeTDS 0.62.4.  The return_status
   seems to always be 0.  Research shows that the problem is probably
   in the CT emulation layer as tsql displays the correct value, but
   sqsh displays 0.

* Output hook patch from Ty Sarna has been applied.

* Applied patch from Andre Sedinin to improve error handling.

* Improved detection of SYBASE_OCS.

- Dave

-- 
http://www.object-craft.com.au

Re: [python-sybase] Sybase module 0.37pre1 released

[Skip M. <sk...@po...>]

    Dave> This release contains a number of small bugfixes and patches
    Dave> received from users.

    ...

I don't see this change:

*** /Users/skip/src/sybase-0.36/Sybase.py       Sun Apr 27 05:54:35 2003
--- /Users/skip/tmp/Sybase.py   Sat Mar 19 16:46:17 2005
***************
*** 436,441 ****
--- 471,477 ----
  
      def start(self, arraysize):
          self._arraysize = arraysize
+         self._set_state(_LAZY_FETCHING)
          status = self._cmd.ct_send()
          if status != CS_SUCCEED:
              self._raise_error(Error, 'ct_send')

You created that in response to some problems one of my users was having.

I also don't see anything related to Python's builtin datetime module.  I
can whip up a patch based upon my local changes if you like.  mx.DateTime is
nice, but overkill for most things and represents yet another thing that
needs to be installed.

Finally, way back when I first started using the Sybase module I added a
converters arg to the Connection class.  I realize that's not necessarily
everybody's idea of the best way to implement type converters, but it allows
me to pretty transparently use whatever date/time module I have available.
(Some users at work have old code that expects times to be floats in epoch
seconds as returned by time.time().  This allows them to easily use that
with minimal changes to their code.)

-- 
Skip Montanaro
sk...@po...

Re: [python-sybase] Sybase module 0.37pre1 released

[Dave C. <dj...@ob...>]

Skip Montanaro wrote:
>     Dave> This release contains a number of small bugfixes and patches
>     Dave> received from users.
> 
>     ...
> 
> I don't see this change:
> 
> *** /Users/skip/src/sybase-0.36/Sybase.py       Sun Apr 27 05:54:35 2003
> --- /Users/skip/tmp/Sybase.py   Sat Mar 19 16:46:17 2005
> ***************
> *** 436,441 ****
> --- 471,477 ----
>   
>       def start(self, arraysize):
>           self._arraysize = arraysize
> +         self._set_state(_LAZY_FETCHING)
>           status = self._cmd.ct_send()
>           if status != CS_SUCCEED:
>               self._raise_error(Error, 'ct_send')
> 
> You created that in response to some problems one of my users was having.

Ooops.  I will put together a pre2 release with that fix and the 
__stdcall patch from Vadim.

I think I should change my strategy for releasing.  Previously I had 
been posting small patches then waiting for feedback.  That seems not to 
work.  A better technique might be to release as soon as a patch is 
received and wait for feedback from that.

> I also don't see anything related to Python's builtin datetime module.  I
> can whip up a patch based upon my local changes if you like.  mx.DateTime is
> nice, but overkill for most things and represents yet another thing that
> needs to be installed.
> 
> Finally, way back when I first started using the Sybase module I added a
> converters arg to the Connection class.  I realize that's not necessarily
> everybody's idea of the best way to implement type converters, but it allows
> me to pretty transparently use whatever date/time module I have available.
> (Some users at work have old code that expects times to be floats in epoch
> seconds as returned by time.time().  This allows them to easily use that
> with minimal changes to their code.)

I like the idea of doing the conversion via a configuration set of 
converters.

Rather than have the set of converters replace the standard set, maybe 
the converters passed to the connection should be merged with the 
standard set for that connection.

- Dave

-- 
http://www.object-craft.com.au