Issue1382581

classification
Title: Jython 2.1 inaccurately reading double(s) from Database
Type: Severity: normal
Components: Core Versions:
Milestone:
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: cgroves, kzuberi
Priority: low Keywords:

Created on 2005-12-16.17:29:09 by anonymous, last changed 2006-09-13.23:19:47 by kzuberi.

Messages
msg1081 (view) Author: Nobody/Anonymous (nobody) Date: 2005-12-16.17:29:09
Jython is inaccurately reading double(s) from Database.

When a database column is defined as double and it is 
value is relatively big (~more than million), jython 
is inaccurately reading the value and it 
adds/subtracts 2,4,8 or 16 (power of 2) to the actual 
value.

The reason is that 
com.ziclix.python.sql.DataHanlder.java uses 
java.sql.ResultSet.getFloat() when reading double 
values instead of using java.sql.ResultSet.getDouble() 
and for large numbers, this has an unexpected behavior.

Here is the relevant piece fo code from 
com.ziclix.python.sql.DataHanlder.java 
public PyObject getPyObject(ResultSet set, int col, 
int type) throws SQLException {

// code here

		case Types.FLOAT :
		case Types.REAL :
		case Types.DOUBLE :
		   obj = Py.newFloat(set.getFloat
(col));
		   break;

// more code here 

}

In our case, we have an amount column defined as 
double in TRADE table. Below are the actual values for 
the amount field and the values retured by Jython. We 
are using zxJDBC to read from the database.

Actual Values in DataBase   Values Returned by Jython
482465000                   482464992
64563750                    64563752
129127500                   129127504


We are using:
- Sybase 12.5 as the database server
- JConnect 5.5 as the JDBC driver.
- Jython 2.1

To temporarly fix this, I had to change DataHandler 
case statement above and use getDouble(col) for 
Types.DOUBLE and the result matched what we have in 
the database.

This is our jython code :-

   d, u, p, v = dburl, dbUsername, dbPassword, 
jdbcDriverClassname
        db = zxJDBC.connect(d, u, p, v)

try:
    c1 = db.cursor()
    c1.execute(sql)
    if c1.rowcount<=0:
        print " NO ROWS TO PROCESS. EXITING NOW"
        c1.close()
        sys.exit(0)
except Exception, e:
    print >> sys.stderr,e
    sys.exit(-1)

for aRow in c1.fetchall():
        stringEntries=[]
        for i in range(len(columnNames)):
                if quotedColumns!=None and columnNames
[i] in quotedColumns:
                        isQuoted=1
                else:
                        isQuoted=0
                stringEntries+=[toString(aRow
[i],quotedChar,isQuoted,autoQuoteSt
rings)]
            print string.join(stringEntries,delimiter)



def toString
(aVariable,quotedString,forceQuote,autoQuoteStrings):
        if aVariable==None:
                returnValue=''
        else:
                   if (autoQuoteStrings and type
(aVariable)==types.StringType) or forceQuote:
                        returnValue=quotedString+str
(aVariable)+quotedString
                else:
                        returnValue=str(aVariable)
        return returnValue
msg1082 (view) Author: Khalid Zuberi (kzuberi) Date: 2005-12-26.02:59:23
Logged In: YES 
user_id=18288


If i understood correctly, you are suggesting the following
simple fix:

Index: DataHandler.java
===================================================================
RCS file:
/cvsroot/jython/jython/com/ziclix/python/sql/DataHandler.java,v
retrieving revision 1.12
diff -u -r1.12 DataHandler.java
--- DataHandler.java	12 May 2005 02:38:59 -0000	1.12
+++ DataHandler.java	26 Dec 2005 02:53:26 -0000
@@ -289,9 +289,12 @@
 
             case Types.FLOAT:
             case Types.REAL:
-            case Types.DOUBLE:
                 obj = Py.newFloat(set.getFloat(col));
                 break;
+            	            	
+            case Types.DOUBLE:
+                obj = Py.newFloat(set.getDouble(col));
+                break;
 
             case Types.TIME:
                 obj = Py.java2py(set.getTime(col));
msg1083 (view) Author: Charlie Groves (cgroves) Date: 2006-09-09.04:41:28
Logged In: YES 
user_id=1174327

Is there a reason this was deferred instead of just being
applied?  The patch Khalid put in seems like a pretty
straightforward fix.
msg1084 (view) Author: Khalid Zuberi (kzuberi) Date: 2006-09-12.16:22:00
Logged In: YES 
user_id=18288


I would guess the deferring was just Frank prioritizing. As
the fix is simple but the error can be quite bad (silently
produce incorrect data), its likely worth committing. If i
don't hear objections i'll put it in (after i figure out how
to setup and run the zxjdbc test suite).

- kz
msg1085 (view) Author: Khalid Zuberi (kzuberi) Date: 2006-09-13.23:19:47
Logged In: YES 
user_id=18288


Fixed in r2938 (2.3 branch) and r2939 (trunk). 

- kz
History
Date User Action Args
2005-12-16 17:29:09anonymouscreate