[
https://issues.apache.org/jira/browse/DBUTILS-42?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12643200#action_12643200
]
brandon.n.atkinson edited comment on DBUTILS-42 at 10/28/08 6:53 AM:
-------------------------------------------------------------------
I disagree the the classification of this as an 'Improvement' issue (sorry if
this is just poor naming by JIRA, I'm not too familiar...).
The comments clearly state that null will be returned if the column value was
null. This is a bug, either in comments or the code.
Looked at the patch that Julien submitted in January. The problem with the fix
he proposes is that null is returned even if the bean property is a primitive
type.
This could cause problems upon assignment , unless there is some smarts higher
up that do some maneuvering.
The fix I propose is less code, and only returns null if the bean property is
an Object type.
was (Author: brandon.n.atkinson):
I disagree the the classification of this as an 'Improvement' issue.
The comments clearly state that null will be returned if the column value was
null. This is a bug, either in comments or the code.
Looked at the patch that Julien submitted in January. The problem with the fix
he proposes is that null is returned even if the bean property is a primitive
type.
This could cause problems upon assignment , unless there is some smarts higher
up that do some maneuvering.
The fix I propose is less code, and only returns null if the bean property is
an Object type.
> 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
> Attachments: BeanProcessor.diff, BeanProcessorAlternativePatch.diff
>
>
> 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
> {code}
> 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;
> }
> {code}
> Hope this helps.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
