[prev in list] [next in list] [prev in thread] [next in thread] 

List:       jakarta-commons-dev
Subject:    [jira] Commented: (DBUTILS-42) Object with Long or Decimal got
From:       Julien_Aymé_(JIRA) <jira () apache ! org>
Date:       2008-01-31 16:55:08
Message-ID: 25399695.1201798508425.JavaMail.jira () brutus
[Download RAW message or body]


    [ https://issues.apache.org/jira/browse/DBUTILS-42?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12564404#action_12564404 \
] 

Julien Aymé commented on DBUTILS-42:
------------------------------------

By looking through the subversion repository, I found that in DbUtils 1.0 only \
rs.getObject(index) was used, which effectively returned <code>null</code> when the \
value is SQL NULL.

The problem is that some database, when using getObject, will return a BigInteger \
instead of a Long (for example), so I assume that this was the (a) reason for which \
the method getLong has been used instead of getObject.

A simple fix could be:

Object res = new Long(rs.getLong(index));
return rs.wasNull() ? null : res;

(And generalize the given code for all the different types in the method \
processColumn).

I will provide the corresponding patch this evening (cannot use svn:checkout at my \
current place, only have a web browser).

Julien

> Object with Long or Decimal got initial zero value while database field is null
> -------------------------------------------------------------------------------
> 
> Key: DBUTILS-42
> URL: https://issues.apache.org/jira/browse/DBUTILS-42
> Project: Commons DbUtils
> Issue Type: Improvement
> Affects Versions: 1.1
> Environment: JDK 5.0, MSSQL 2000
> Reporter: Matt Jiang
> 
> While I use dbutil1.1, I got a big different implementation betweeb 1.0 and 1.1.
> Given a Java object, it has a property with Long data type; mapping to database, \
> its table field datatype is bigint. If it has a record and its value is null.
> In 1.0 implementation, if I load entity, then we can see the property in Java \
> object is also null. But in 1.1 implementation, the Java object will got a Long \
> object with 0 inside. This behavior change does big impact if I upgrade from 1.0 to \
> 1.1. It might make application logic fail because origional null status now become \
> a Long(0) value to map to null value in database. I suggest to change it back. If \
> null value in database, then mapped Java object should be null as well, not new a \
> Long(0) to be a initial value. Below is the code snapshot I used to execute query, \
> and I use jTDS 1.2 as JDBC driver public List<E> executePreparedQuery(String sql, \
> Object[] params, Class clazz) throws SQLException { 
> Connection cnct = getConnection();
> QueryRunner qRunner = new QueryRunner();
> ResultSetHandler rsHandler = new BeanListHandler(clazz);
> List<E> entities = null;
> try {
> 	convertDateIn(params);
> 	entities = (List<E>) qRunner.query(cnct, sql, params, rsHandler);
> }
> catch (SQLException e) {
> 	e.printStackTrace();
> 	throw e;
> }
> finally {
> 	closeConnection();
> }
> return entities;
> }
> Hope this helps.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[prev in list] [next in list] [prev in thread] [next in thread]