pydb2-discuss

[PyDB2-discuss] I have a patch to handle SQL_SUCCESS_WITH_INFO

[Preston L. <pla...@jo...>]

Greetings to all on the list.

I'm not seeing much activity on this list or with the driver in general.
I'm not sure if that means not many people are using it, or maybe it just
works so well there's not much to discuss or change. ;-)

We here at Journyx, Inc. (www.journyx.com - free timekeeping for 10 users
or less) have been using this driver with good results for a while now.
Most of our customers are NOT using DB2 (most are on Postgresql, SQL
Server, and Oracle) but the few who do are depending on this driver for
their production Time and Expense data.

We ran into a situation recently where we wanted to use a certain
construct in DB2 that was generating the SQL0347W warning about recursion.
The DB2.py driver was raising this non-fatal warning as a error (and not
returning the result rows.)

Digging a bit deeper I found that this is the SQL_SUCCESS_WITH_INFO result
code.  The current driver (_db2_module.c) has a comment to the effect of
"need to cope with SQL_SUCCESS_WITH_INFO."

I took what seemed to me to be the most simple and direct route to fix
this problem.  I simply added a 'LastWarningString' attribute to the
internal cursor object.  This is cleared before every statement execution.
If SQL_SUCCESS_WITH_INFO is encountered then LastWarningString is updated
with the warning text, and the result rows are returned.

It is then up to the caller to check LastWarningString after every query
if they care about that.  I also made a minor change in DB2.py BaseCursor
class to copy over the LastWarningString in _refresh_info().

I thought these changes would be generally useful.  Unless there is
disagreement about the design (LastWarningString) the changes should be
ready to patch into the latest version.  I'm open to suggestions for a
better design to handle SQL_SUCCESS_WITH_INFO.

What is the best way to provide a patch such as this?  Should I just
attach the new versions of the files to an email to this list and let a
maintainer diff the changes in?

thanks,

Preston Landers - pla...@jo...
Senior Software Developer, Journyx, Inc.
Austin, Texas  (512) 225-3929

Re: [PyDB2-discuss] I have a patch to handle SQL_SUCCESS_WITH_INFO

[Yuval T. <yu...@il...>]

Preston Landers wrote:

>Greetings to all on the list.
>
>I'm not seeing much activity on this list or with the driver in general.
>I'm not sure if that means not many people are using it, or maybe it just
>works so well there's not much to discuss or change. ;-)
>
>We here at Journyx, Inc. (www.journyx.com - free timekeeping for 10 users
>or less) have been using this driver with good results for a while now.
>Most of our customers are NOT using DB2 (most are on Postgresql, SQL
>Server, and Oracle) but the few who do are depending on this driver for
>their production Time and Expense data.
>
>We ran into a situation recently where we wanted to use a certain
>construct in DB2 that was generating the SQL0347W warning about recursion.
>The DB2.py driver was raising this non-fatal warning as a error (and not
>returning the result rows.)
>
>Digging a bit deeper I found that this is the SQL_SUCCESS_WITH_INFO result
>code.  The current driver (_db2_module.c) has a comment to the effect of
>"need to cope with SQL_SUCCESS_WITH_INFO."
>
>I took what seemed to me to be the most simple and direct route to fix
>this problem.  I simply added a 'LastWarningString' attribute to the
>internal cursor object.  This is cleared before every statement execution.
>If SQL_SUCCESS_WITH_INFO is encountered then LastWarningString is updated
>with the warning text, and the result rows are returned.
>
>It is then up to the caller to check LastWarningString after every query
>if they care about that.  I also made a minor change in DB2.py BaseCursor
>class to copy over the LastWarningString in _refresh_info().
>
>I thought these changes would be generally useful.  Unless there is
>disagreement about the design (LastWarningString) the changes should be
>ready to patch into the latest version.  I'm open to suggestions for a
>better design to handle SQL_SUCCESS_WITH_INFO.
>
>What is the best way to provide a patch such as this?  Should I just
>attach the new versions of the files to an email to this list and let a
>maintainer diff the changes in?
>
>thanks,
>
>Preston Landers - pla...@jo...
>Senior Software Developer, Journyx, Inc.
>Austin, Texas  (512) 225-3929
>  
>
Could you post your patch here ?
Thanks!

-- 
Yuval Turgeman
Content Technology, Aduva LTD.

Re: [PyDB2-discuss] I have a patch to handle SQL_SUCCESS_WITH_INFO

[<po...@or...>]

Preston Landers <pla...@jo...> writes:

> Greetings to all on the list.

Same to you.  Nice to have you on the list.

> What is the best way to provide a patch such as this?  Should I just
> attach the new versions of the files to an email to this list and
> let a maintainer diff the changes in?

I was hoping Man-Yong Lee would respond.  If we don't hear from him
soon, what I can do is add you as a developer to the project and you
can patch the code and update it yourself.

Do you have a SourceForge username?

-- 
Patrick K. O'Brien
Orbtech      http://www.orbtech.com/web/pobrien
-----------------------------------------------
"Your source for Python programming expertise."
-----------------------------------------------

[PyDB2-discuss] Re: I have a patch to handle SQL_SUCCESS_WITH_INFO

[Preston L. <pla...@jo...>]

On Wed, 14 Jan 2004, Preston Landers wrote:

> We ran into a situation recently where we wanted to use a certain
> construct in DB2 that was generating the SQL0347W warning about recursion.
> The DB2.py driver was raising this non-fatal warning as a error (and not
> returning the result rows.)
>
> Digging a bit deeper I found that this is the SQL_SUCCESS_WITH_INFO result
> code.  The current driver (_db2_module.c) has a comment to the effect of
> "need to cope with SQL_SUCCESS_WITH_INFO."
>
> I took what seemed to me to be the most simple and direct route to fix
> this problem.  I simply added a 'LastWarningString' attribute to the
> internal cursor object.  This is cleared before every statement execution.
> If SQL_SUCCESS_WITH_INFO is encountered then LastWarningString is updated
> with the warning text, and the result rows are returned.
>
> It is then up to the caller to check LastWarningString after every query
> if they care about that.  I also made a minor change in DB2.py BaseCursor
> class to copy over the LastWarningString in _refresh_info().


Attached are the three files that I modified to make this change.

_db2_module.c  -- handle SQL_SUCCESS_WITH_INFO by setting the warning
                  to a cursor variable LastWarningString

DB2.py  -- copy over LastWarningString in _refresh_info().
           Also changed 'x in dict' Python 2.2 syntax to the
           equivelent has_key() so it will work with Py 2.1.

README -- just added a note about checking LastWarningString

By the way, my Sourceforge account is 'planders'.

thanks,

---
Preston Landers - pla...@jo...
Senior Software Developer, Journyx, Inc.
Austin, Texas  (512) 225-3929

Re: [PyDB2-discuss] Re: I have a patch to handle SQL_SUCCESS_WITH_INFO

[<po...@or...>]

Preston Landers <pla...@jo...> writes:

> By the way, my Sourceforge account is 'planders'.

You are now a developer.  Feel free to update the source files.  I've
also given you release privileges, so that you can package up a file
release.  Thank you very much for your contributions.  They are
greatly appreciated.

-- 
Patrick K. O'Brien
Orbtech      http://www.orbtech.com/web/pobrien
-----------------------------------------------
"Your source for Python programming expertise."
-----------------------------------------------

[PyDB2-discuss] Re: I have a patch to handle SQL_SUCCESS_WITH_INFO

[Preston L. <pla...@jo...>]

On 15 Jan 2004, Patrick K. O'Brien wrote:

> Preston Landers <pla...@jo...> writes:
>
> > By the way, my Sourceforge account is 'planders'.
>
> You are now a developer.  Feel free to update the source files.  I've
> also given you release privileges, so that you can package up a file
> release.  Thank you very much for your contributions.  They are
> greatly appreciated.

OK.  I will work on that within the next week or so.  I'm a bit tied up
at the moment.

Does anyone have an issue with the solution that I chose to handle the
SQL_SUCCESS_WITH_INFO state?  To remind you, that is the case where an
operation worked (e.g. returned rows) and yet there is a warning string
from the database server.   The solution I chose was just to stuff the
warning string into a LastWarningString attribute of the cursor object and
rely on the caller to check the string if they care.  Previously, the
driver was raising the warning as if it were a fatal error.

The only scenario I can think of where this change may break someone is if
they were for some obscure reason relying on the warnings being raised as
errors.