
|
If you were logged in you would be able to see more operations.
|
|
|
|
File Attachments:
|
|
|
Environment:
|
JDK 5.0, MSSQL 2000
|
|
| Resolution Date: |
25/Feb/09 10:02 AM
|
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.
|
|
Description
|
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. |
Show » |
made changes - 18/Oct/07 03:04 AM
| Field |
Original Value |
New Value |
|
Description
|
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.
|
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.
|
made changes - 16/Mar/08 09:45 PM
|
Description
|
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.
|
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.
|
made changes - 09/Jan/09 03:06 AM
|
Fix Version/s
|
|
1.2
[ 12312139
]
|
made changes - 25/Feb/09 10:02 AM
|
Resolution
|
|
Fixed
[ 1
]
|
|
Status
|
Open
[ 1
]
|
Closed
[ 6
]
|
made changes - 07/Mar/09 06:09 AM
|
Assignee
|
|
Dan Fabulich
[ dfabulich
]
|
|