[jira] Commented: (IBATIS-303) SqlMapExecutor.executeBatch() returns 0
[ http://issues.apache.org/jira/browse/IBATIS-303?page=comments#action_12415107 ] Sven Boden commented on IBATIS-303: --- It's a known problem, and it's not going to be solved. It's not in iBATIS, it's a problem with Oracle's driver. The JDBC spec allows vendors to skip certain functionality in executeBatch and this is what Oracle does, they return -2 for updates in executeBatch which iBATIS translates to 0. Oracle just doesn't return the number of rows being updated for prepared statements. From the Oracle 9i documentation: For a prepared statement batch, it is not possible to know the number of rows affected in the database by each individual statement in the batch. Therefore, all array elements have a value of -2. According to the JDBC 2.0 specification, a value of -2 indicates that the operation was successful but the number of rows affected is unknown. SqlMapExecutor.executeBatch() returns 0 --- Key: IBATIS-303 URL: http://issues.apache.org/jira/browse/IBATIS-303 Project: iBatis for Java Type: Bug Components: SQL Maps Versions: 2.1.7 Environment: Oracle 9, OCI driver Reporter: george apostolov SqlMapExecutor.executeBatch() returns 0 on Oracle 9 using the oci jdbc driver. I saw someone had the same issue before but this still seems to be a problem Thanks, George -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (IBATIS-303) SqlMapExecutor.executeBatch() returns 0
[
http://issues.apache.org/jira/browse/IBATIS-303?page=comments#action_12415157 ]
Sven Boden commented on IBATIS-303:
---
I would suggest to take this to the iBATIS development list, this is more a
support problem not an iBATIS issue. I will close this JIRA shortly as
invalid.
You've answered you're own problem... use transactions. Something as:
try {
sqlMaps.startTransaction();
sqlMap.startBatch();
// map stuff
Map args = CollectionUtil.createMap(2);
for(int i=0;ip_resultList.size();i++)
{
AdvancedSearchResultData resultData =
(AdvancedSearchResultData)p_resultList.get(i);
args.put(RESULT_DATA, resultData);
args.put(UserIdentifier, p_userID);
sqlMap.insert(insertIntoTempTable, args);
}
sqlMap.executeBatch();
sqlMap.commitTransaction();
} finally {
sqlMap.endTransaction();
}
Regards,
Sven
SqlMapExecutor.executeBatch() returns 0
---
Key: IBATIS-303
URL: http://issues.apache.org/jira/browse/IBATIS-303
Project: iBatis for Java
Type: Bug
Components: SQL Maps
Versions: 2.1.7
Environment: Oracle 9, OCI driver
Reporter: george apostolov
SqlMapExecutor.executeBatch() returns 0 on Oracle 9 using the oci jdbc driver.
I saw someone had the same issue before but this still seems to be a problem
Thanks,
George
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (IBATIS-288) Sometimes iBatis does not insert BLOBs using autocommit.
[ http://issues.apache.org/jira/browse/IBATIS-288?page=comments#action_12374702 ] Sven Boden commented on IBATIS-288: --- I don't think this is a bug. It does work when you explicitly demarcate transactions. The default is to rollback, so unless you commit you lose your changes. And this probably is what's happening. In the 30% where it works you will probably commit for other stuff. Sometimes iBatis does not insert BLOBs using autocommit. Key: IBATIS-288 URL: http://issues.apache.org/jira/browse/IBATIS-288 Project: iBatis for Java Type: Bug Components: SQL Maps Versions: 2.1.5 Environment: I am working with Oracle 9.2.0.4 using Oracle Thin driver for 10g2. The client application is running on WIndows XP using JVM 1.4.2_10 and Oracle is running in a SUSE Enterprise Server 9. Reporter: Vladimir Alarcón Priority: Minor When inserting an object with a BLOB property, WITHOUT explicit transaction demarcation, sometimes (approx 30%) it silently does nothing (it does not insert, but also it does not fail). The other times it inserts the line in the table without any problems. I have found that the workaround is to always EXPLICITLY DEMARCATE transactions, when inserting BLOBs. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (IBATIS-259) SqlMapTransactionManager.setUserConnection(null) does not completely restore previous transaction state
[ http://issues.apache.org/jira/browse/IBATIS-259?page=all ]
Sven Boden closed IBATIS-259:
-
Resolution: Invalid
Assign To: Sven Boden
Closed as announced as invalid.
SqlMapTransactionManager.setUserConnection(null) does not completely restore
previous transaction state
---
Key: IBATIS-259
URL: http://issues.apache.org/jira/browse/IBATIS-259
Project: iBatis for Java
Type: Bug
Components: SQL Maps
Versions: 2.1.7, 2.1.6, 2.1.5
Reporter: Paul Wilton
Assignee: Sven Boden
SqlMapTransactionManager.setUserConnection(null) does not completely restore
previous transaction state:
// 0) ... transaction manager setup as below
transactionManager type=JDBC
dataSource type=JNDI
property name=DBInitialContext value=java:comp/env/
property name=DBLookup value=/jdbc/dbname/
/dataSource
/transactionManager
PSEUDO CODE DEMONSTRATING PROBLEM AS FOLLOWS:
// 1) ... start transaction using DaoManager
DaoManager.startTransaction()
// perform some query using this transaction:
getSqlMapExecutor().queryForList(statementName, parameterObject);
// 2) ... perform some query with userConnection:
SqlMapExecutor executor = getSqlMapExecutor();
SqlMapTransactionManager tm = getSqlMapTransactionManager();
Connection userConn = null;
try {
// get a new connection from pool and set it to autocommit mode
true for this query
userConn = tm.getDataSource().getConnection();
tm.setUserConnection(userConn);
// execute the query
list = executor.queryForList(statementName, parameterObject);
} catch (SQLException e) {
// do something
} finally {
try {
// close the user connection
if (userConn!=null)
userConn.close();
// set the user connection back to null, so any transaction
on the other connection can be continued
tm.setUserConnection(null); // THIS SHOULD RESTORE THE
ORGINAL TRANSACTION STATE
} catch (SQLException e) {
// do something
}
}
// 3) ... perform another query using orginal transaction:
getSqlMapExecutor().queryForList(statementName, parameterObject);
// THIS FAILS - stacktracing with null pointer exception as follows:
java.lang.NullPointerException
at
com.ibatis.sqlmap.engine.impl.SqlMapExecutorDelegate.autoEndTransaction(SqlMapExecutorDelegate.java:860)
at
com.ibatis.sqlmap.engine.impl.SqlMapExecutorDelegate.queryForList(SqlMapExecutorDelegate.java:617)
at
com.ibatis.sqlmap.engine.impl.SqlMapExecutorDelegate.queryForList(SqlMapExecutorDelegate.java:584)
at
com.ibatis.sqlmap.engine.impl.SqlMapSessionImpl.queryForList(SqlMapSessionImpl.java:101)
at
com.ibatis.sqlmap.engine.impl.SqlMapClientImpl.queryForList(SqlMapClientImpl.java:78)
at
nz.govt.nzqa.web.persistence.ibatis.sqlmap.BaseDaoImpl.executeQueryForList(BaseDaoImpl.java:63)
// 4) .. end original transaction using DaoManager - commit or rollback
DaoMoanager.commitTransaction();
DaoMoanager.endTransaction();
// This never executes due to previous failure
--
This failure appears to be caused by
SqlMapTransactionManager.setUserConnection(null) failing to restore the
original transaction state.
In the following methods of class SqlMapExecutorDelegate,
pushSession(session) resets the session thus setting the transaction manager
for the session to NULL. Consequently when step 3 (above) is executed ibatis
stack traces.
public void setUserProvidedTransaction(SessionScope session, Connection
userConnection) {
if (session.getTransactionState() ==
TransactionState.STATE_USER_PROVIDED) {
session.recallTransactionState();
}
if (userConnection != null) {
Connection conn = userConnection;
session.saveTransactionState();
session.setTransaction(new UserProvidedTransaction(conn));
session.setTransactionState(TransactionState.STATE_USER_PROVIDED);
} else {
session.setTransaction(null);
pushSession(session);
}
}
protected void pushSession(SessionScope session) {
session.reset();
sessionPool.push(session);
}
EXPECTED OPERATION:
What I expect to happen when setUserConnection(null) is called is that the
original transaction (and thus connection) is restored in its entirety so
that subsequent queries can be made, and the transaction can be commited (or
rolled back) as a unit - with the query made on the user connection outside
of this transaction scope.
--
This message is
[jira] Closed: (IBATIS-127) PropertyAccessPlan should put more context information when throwing an exception
[ http://issues.apache.org/jira/browse/IBATIS-127?page=all ] Sven Boden closed IBATIS-127: - Fix Version: 2.2.0 Resolution: Fixed Assign To: Sven Boden Closed because fix is in SVN. PropertyAccessPlan should put more context information when throwing an exception - Key: IBATIS-127 URL: http://issues.apache.org/jira/browse/IBATIS-127 Project: iBatis for Java Type: Improvement Components: SQL Maps Versions: 2.0.8 Environment: iBatis 2.0.7 Reporter: Jerome Lacoste Assignee: Sven Boden Priority: Trivial Fix For: 2.2.0 Attachments: ibatis-2.0.7_PropertyAccessPlan_more_context_information.txt It's hard to find the reason of a failure. By adding more context information it becomes much easier to know what is wrong. See attached patch. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (IBATIS-216) Optional property in resultmap
[ http://issues.apache.org/jira/browse/IBATIS-216?page=all ] Sven Boden closed IBATIS-216: - Resolution: Duplicate Assign To: Sven Boden Closed as duplicate (as announced before) Optional property in resultmap -- Key: IBATIS-216 URL: http://issues.apache.org/jira/browse/IBATIS-216 Project: iBatis for Java Type: New Feature Reporter: Paul Benedict Assignee: Sven Boden I would find it useful to have optional properties in a resultmap. I don't want to have specialized maps for different queries which may return different number of columns for the same object type. I think an optional attribute would be helpful: result property=description column=DESC optional=true / -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (IBATIS-206) Support for JDBC 3.0 Disconnected Resultsets such as WebRowSet/CachedRowSet etc
[ http://issues.apache.org/jira/browse/IBATIS-206?page=all ] Sven Boden closed IBATIS-206: - Resolution: Won't Fix Assign To: Sven Boden Closed as won't fix, since I got no objections. Support for JDBC 3.0 Disconnected Resultsets such as WebRowSet/CachedRowSet etc --- Key: IBATIS-206 URL: http://issues.apache.org/jira/browse/IBATIS-206 Project: iBatis for Java Type: New Feature Components: SQL Maps Versions: 2.1.5 Environment: JDBC WebRowSet support Reporter: Abdullah Kauchali Assignee: Sven Boden Is there any chance of having sqlMapClient return a WebRowSet instance? SqlMapClient.getWebRowSet( ...) ? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (IBATIS-216) Optional property in resultmap
[ http://issues.apache.org/jira/browse/IBATIS-216?page=comments#action_12371130 ] Sven Boden commented on IBATIS-216: --- This is a duplicate of IBATIS-115, so I'm going to close this one as duplicate around March, 24 Optional property in resultmap -- Key: IBATIS-216 URL: http://issues.apache.org/jira/browse/IBATIS-216 Project: iBatis for Java Type: New Feature Reporter: Paul Benedict I would find it useful to have optional properties in a resultmap. I don't want to have specialized maps for different queries which may return different number of columns for the same object type. I think an optional attribute would be helpful: result property=description column=DESC optional=true / -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (IBATIS-216) Optional property in resultmap
[ http://issues.apache.org/jira/browse/IBATIS-216?page=comments#action_12371132 ] Sven Boden commented on IBATIS-216: --- This is a duplicate of IBATIS-115 so I'm going to close this as duplicate around March, 24th Optional property in resultmap -- Key: IBATIS-216 URL: http://issues.apache.org/jira/browse/IBATIS-216 Project: iBatis for Java Type: New Feature Reporter: Paul Benedict I would find it useful to have optional properties in a resultmap. I don't want to have specialized maps for different queries which may return different number of columns for the same object type. I think an optional attribute would be helpful: result property=description column=DESC optional=true / -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (IBATIS-127) PropertyAccessPlan should put more context information when throwing an exception
[ http://issues.apache.org/jira/browse/IBATIS-127?page=comments#action_12371137 ] Sven Boden commented on IBATIS-127: --- I've tested different combinations on a couple of people... I would like to make the error messages as follows: --- Cause: java.lang.RuntimeException: Error setting property 'setCartOption' of '[EMAIL PROTECTED]'. Cause: java.lang.IllegalArgumentException: argument type mismatch instead of the current: --- Cause: java.lang.RuntimeException: Error setting properties of '[EMAIL PROTECTED]'. Cause: java.lang.IllegalArgumentException: argument type mismatch so halfway between the current version and the proposed version. Closure around March, 24th. PropertyAccessPlan should put more context information when throwing an exception - Key: IBATIS-127 URL: http://issues.apache.org/jira/browse/IBATIS-127 Project: iBatis for Java Type: Improvement Components: SQL Maps Versions: 2.0.8 Environment: iBatis 2.0.7 Reporter: Jerome Lacoste Priority: Trivial Attachments: ibatis-2.0.7_PropertyAccessPlan_more_context_information.txt It's hard to find the reason of a failure. By adding more context information it becomes much easier to know what is wrong. See attached patch. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (IBATIS-206) Support for JDBC 3.0 Disconnected Resultsets such as WebRowSet/CachedRowSet etc
[ http://issues.apache.org/jira/browse/IBATIS-206?page=comments#action_12371139 ] Sven Boden commented on IBATIS-206: --- Since iBATIS is more about getting objects out of the data (and back into) then returning Resultsets (the old style or the new style), I would rather not implement IBATIS-206 Closure around March, 24th (unless objections) Support for JDBC 3.0 Disconnected Resultsets such as WebRowSet/CachedRowSet etc --- Key: IBATIS-206 URL: http://issues.apache.org/jira/browse/IBATIS-206 Project: iBatis for Java Type: New Feature Components: SQL Maps Versions: 2.1.5 Environment: JDBC WebRowSet support Reporter: Abdullah Kauchali Is there any chance of having sqlMapClient return a WebRowSet instance? SqlMapClient.getWebRowSet( ...) ? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (IBATIS-222) Evict from cache
[
http://issues.apache.org/jira/browse/IBATIS-222?page=comments#action_12371004 ]
Sven Boden commented on IBATIS-222:
---
The request to evict objects based on primary key is not really valid as iBATIS
does not use object identity: the results are cached, not the seperate objects.
So e.g. if 2 queries would return the same object you would find the object
twice in the cache.
One current solution would be to switch off iBATIS caching and roll your own
caching on the DAO level. In the future iBATIS caching may be pluggable and it
will be possible to replace the caching strategy (but that request is open as
another JIRA).
I would like to close this JIRA on March, 24th unless objections appear.
Evict from cache
Key: IBATIS-222
URL: http://issues.apache.org/jira/browse/IBATIS-222
Project: iBatis for Java
Type: New Feature
Components: SQL Maps
Versions: 2.1.6
Reporter: Paul Benedict
I use the cache mainly to keep in memory objects which are very expensive to
create and are retrieved very often throughout the lifetime of my system.
These objects are also updatable and so I need to refresh them when an
insert/update is called.
The current implemention allows a flushOnExecute tag to define the methods
to flush, but this is too coarse. I request an enhancement to allow me to
evict only certain objects (specified by primary keys) so that I do not have
to flush the entire cache for a single object update. It is too costly to
throw away 1000s of objects just for one update.
Either the cache should be exposed through a method so that the developer can
programtically evict the correct object or some sort of automated process
should do it as such:
!-- flush the object in the cache having properties id1 id2 set to the
object just passed into insertArticle --
flushOnExecute method=insertArticle id={id1,id2}
I personally prefer having programatic access... at least until IBATIS can do
it all for me :)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (IBATIS-211) Cache should follow structure of hierarchical resultmaps
[ http://issues.apache.org/jira/browse/IBATIS-211?page=comments#action_12371006 ] Sven Boden commented on IBATIS-211: --- The request for caching to follow the structure of ResultMaps is not valid as iBATIS does not use object identity: the results are cached, not the seperate objects. So e.g. if 2 queries would return the same object you would find the object twice in the cache. What I could possible envision is a kind of flushOnFlush statement which cascade cache flushes whenever a cache is flushed (taking care of cyclic dependencies, ...). It would be relatively easy to implement but currently I don't see a real need for it. So similar as IBATIS-222 I would like to close this JIRA around March, 24th Cache should follow structure of hierarchical resultmaps Key: IBATIS-211 URL: http://issues.apache.org/jira/browse/IBATIS-211 Project: iBatis for Java Type: Improvement Components: SQL Maps Environment: n/a Reporter: Reuben Firmin Assume 3 sqlMaps, A, B, C. A has resultMapA, which contains a mapping to a select query in B, which in turn maps to Cs. In other words, we have: B[] A.getBs(); C[] B.getCs(); When a cache (cacheA) is implemented at A, the Bs and Cs are also cached in it (cacheA), despite the existence of cacheB and cacheC at their respective levels. This means that flushOnExecute statements must be defined for B and C on cacheA's declaration, *i.e. within A's namespace*. This is error prone, since development on B or C is affected by the cache on A; somebody adding or renaming a mutator on B or C would not necessarily know that they have to add or edit a corresponding flushOnExecute to cacheA. The logic (perhaps optional) should be: If resultMapA maps to other sqlMaps, and those sqlMaps have their own caches, then *defer to those caches to cache those objects*. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (IBATIS-120) Use of java.util.List for imput parameter
[ http://issues.apache.org/jira/browse/IBATIS-120?page=comments#action_12371008 ] Sven Boden commented on IBATIS-120: --- I would like to close IBATIS-120 feature request as won't fix as it would introduce bad practices. Closure around March, 24th. Use of java.util.List for imput parameter - Key: IBATIS-120 URL: http://issues.apache.org/jira/browse/IBATIS-120 Project: iBatis for Java Type: New Feature Components: SQL Maps Environment: N/A Reporter: Dharmendra Chauhan Priority: Minor Manytimes I need to just pass parameters to sql not object properties. In such case it makes more sense to pass List object rather than Map. e.g. update contact set age=? where user=? Here I should be able to pass java.util.List object with Integer at first (0) index and String at next index. This is less verbose option than others. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (IBATIS-275) Update SqlMapClient's flushDataCache document to indicated namespace required
[ http://issues.apache.org/jira/browse/IBATIS-275?page=all ] Sven Boden closed IBATIS-275: - Resolution: Fixed Assign To: Sven Boden Done Update SqlMapClient's flushDataCache document to indicated namespace required - Key: IBATIS-275 URL: http://issues.apache.org/jira/browse/IBATIS-275 Project: iBatis for Java Type: Improvement Components: Documentation Versions: 2.1.5 Environment: WinXP, J2SE1.4.1 Reporter: Joe Wolf Assignee: Sven Boden Attachments: SqlMapParser.java, SqlStatementParser.java SqlMapClient's flushDataCache method throws an exception if you do not prefix the cache model id with the namespace in which it is defined. For example, if I have a cacheModel with id=bob inside an sqlMap with namespace=Foo, I must call flushDataCache(Foo.bob) instead of flushDataCache(bob), even if I have useStatementNamespaces=false in my SQLMapConfig's settigns. It would be nice if the javadocs of the flushDataCache indicated that the namespace was required. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (IBATIS-204) Cache layer does no logging of puts, gets, flushes, or removals.
[ http://issues.apache.org/jira/browse/IBATIS-204?page=all ] Sven Boden closed IBATIS-204: - Administrative close Cache layer does no logging of puts, gets, flushes, or removals. Key: IBATIS-204 URL: http://issues.apache.org/jira/browse/IBATIS-204 Project: iBatis for Java Type: Improvement Components: SQL Maps Versions: 2.0.8, 2.0.9, 2.1.0, 2.0.9b, 2.1.5, 2.1.6, 2.2.5 Environment: All Reporter: michael campbell Assignee: Sven Boden Priority: Minor Fix For: 2.2.0 Attachments: CacheModel.java The cache layer has no logging. Following is the code change I made (all cache mechanisms EXCEPT os-cache) to the cache code which suits my purposes. I tried to stay within the spirit of the existing logging, mimicing the output formats, etc. Released to the public domain. [...source snipped...] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (IBATIS-265) Map data into HashMaps: HashMap of List of HashMaps
[ http://issues.apache.org/jira/browse/IBATIS-265?page=all ]
Sven Boden closed IBATIS-265:
-
Resolution: Invalid
Assign To: Sven Boden
Use a HashMap as resultClass and use queryForList()... you will get a list of
HashMaps. No changes are required as it's already supported.
Map data into HashMaps: HashMap of List of HashMaps
---
Key: IBATIS-265
URL: http://issues.apache.org/jira/browse/IBATIS-265
Project: iBatis for Java
Type: Improvement
Reporter: Stefan Friedrich
Assignee: Sven Boden
Priority: Minor
We tried to implement the HashMaps as results for our queries. The problem
is, that whenever a HashMap is set as the resultClass, a queryForObject is
called and so, every select can only return ONE result. In our application we
expect a list of HashMaps at certain locations. The solution for our problem
would be very simple and - in our opinion - would work with only three new
lines of code:
The Method BasicResultMap.getResults(RequestScope request, ResultSet rs) the
targetType for further calls is set:
if (resultClass == null) {
throw new SqlMapException(The result class was null when trying to get
results for ResultMap named + getId() + .);
} else if (Map.class.isAssignableFrom(resultClass)) {
columnValues[i] = getNestedSelectMappingValue(request, rs, mapping,
Object.class);
} else if (DomTypeMarker.class.isAssignableFrom(resultClass)) {
Class javaType = mapping.getJavaType();
if (javaType == null) {
javaType = DomTypeMarker.class;
}
columnValues[i] = getNestedSelectMappingValue(request, rs, mapping,
javaType);
} else {
Probe p = ProbeFactory.getProbe(resultClass);
Class type = p.getPropertyTypeForSetter(resultClass,
mapping.getPropertyName());
columnValues[i] = getNestedSelectMappingValue(request, rs, mapping,
type);
}
The part that needs to be changed is in the first else-Statement.
if (resultClass == null) {
throw new SqlMapException(The result class was null when trying to get
results for ResultMap named + getId() + .);
} else if (Map.class.isAssignableFrom(resultClass)) {
Class javaType = mapping.getJavaType();
if (javaType == null) {
javaType = Object.class;
}
columnValues[i] = getNestedSelectMappingValue(request, rs, mapping,
javaType);
} else if (DomTypeMarker.class.isAssignableFrom(resultClass)) {
Class javaType = mapping.getJavaType();
if (javaType == null) {
javaType = DomTypeMarker.class;
}
columnValues[i] = getNestedSelectMappingValue(request, rs, mapping,
javaType);
} else {
Probe p = ProbeFactory.getProbe(resultClass);
Class type = p.getPropertyTypeForSetter(resultClass,
mapping.getPropertyName());
columnValues[i] = getNestedSelectMappingValue(request, rs, mapping,
type);
}
As you can see, the changes would have no effect, if no javaType was set. But
for our concerns, we would set the javaType to java.util.ArrayList and
everything would be just fine!
Stefan
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (IBATIS-275) Update SqlMapClient's flushDataCache document to indicated namespace required
[ http://issues.apache.org/jira/browse/IBATIS-275?page=comments#action_12369723 ] Sven Boden commented on IBATIS-275: --- Attachments to JIRA make cache models namespace sensitive. However this would break configurations using flushDataCache(String ...) when not namespaces are not active. So I guess we're not going to implement this. Any other ideas? Update SqlMapClient's flushDataCache document to indicated namespace required - Key: IBATIS-275 URL: http://issues.apache.org/jira/browse/IBATIS-275 Project: iBatis for Java Type: Improvement Components: Documentation Versions: 2.1.5 Environment: WinXP, J2SE1.4.1 Reporter: Joe Wolf Attachments: SqlMapParser.java, SqlStatementParser.java SqlMapClient's flushDataCache method throws an exception if you do not prefix the cache model id with the namespace in which it is defined. For example, if I have a cacheModel with id=bob inside an sqlMap with namespace=Foo, I must call flushDataCache(Foo.bob) instead of flushDataCache(bob), even if I have useStatementNamespaces=false in my SQLMapConfig's settigns. It would be nice if the javadocs of the flushDataCache indicated that the namespace was required. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (IBATIS-274) queryForPaginatedList doesn't play well with groupBy attribute of resultMap (N+1 selects solution)
[
http://issues.apache.org/jira/browse/IBATIS-274?page=comments#action_12369315 ]
Sven Boden commented on IBATIS-274:
---
I think that at the moment using queryForPaginatedList together with groupBy is
an undefined behaviour. It runs but it's undefined. Using a normal groupBy
causes all rows to be read and puts all objects in the right object bucket
(according to the groupBy), using paginatedList doesn't allow this because not
all rows are inspected.
queryForPaginatedList doesn't play well with groupBy attribute of resultMap
(N+1 selects solution)
---
Key: IBATIS-274
URL: http://issues.apache.org/jira/browse/IBATIS-274
Project: iBatis for Java
Type: Bug
Components: SQL Maps
Versions: 2.1.7
Environment: WinXP Pro, WebLogic 8.1, JDK 1.4.2_05, Spring 1.2.7
Reporter: Tim Haley
I have implemented the N+1 solution using the groupBy attribute of the
resultMap.
When this is called using queryForList() it works as expected; I get two
BatchResults objects, the first contains a list of 20 ProcessingResult
objects and the second contains a list of 19 ProcessingResult objects.
When called with queryForPaginatedList() and a page size of 10, I only get
the first BatchResults object, which does contain the list of 20
ProcessingResult objects.
When called with queryForPaginatedList() and a page size of 19, I only get
both BatchResults objects, the first contains a list of 20 ProcessingResult
objects and the second contains a list of 18 ProcessingResult objects. (total
of 38, 2x the page size)
When called with queryForPaginatedList() and a page size of 18, I only get
both BatchResults objects, the first contains a list of 20 ProcessingResult
objects and the second contains a list of 16 ProcessingResult objects. (total
of 36, 2x the page size)
When called with queryForPaginatedList() and a page size of 17, I only get
both BatchResults objects, the first contains a list of 20 ProcessingResult
objects and the second contains a list of 14 ProcessingResult objects. (total
of 34, 2x the page size)
See details of mapping and method calls below:
resultMap id=BatchResultMap class=BatchResult
groupBy=processingSchedule.processingKey
result property=processingSchedule.processingKey
column=PROCESSING_KEY javaType=int/
result property=processingSchedule.processingDate
column=PROCESS_DATE javaType=date/
result property=processingSchedule.printDate column=PRINT_DATE
javaType=date/
result property=processingSchedule.processType.processTypeKey
column=PROCESS_TYPE_KEY javaType=int/
result property=processingSchedule.processType.description
column=PROCESS_TYPE_DESCRIPTION javaType=string/
result property=processingResults
resultMap=Processing.ProcessResultMap/
/resultMap
resultMap id=ProcessResultMap class=ProcessingResult
!--result property=processingKey column=PR_PROCESSING_KEY/--
result property=applicationKey column=APPLICATION_KEY
javaType=int/
result property=applicationStatusKey
column=APPLICATION_STATUS_KEY javaType=int/
result property=applicationStatusString
column=APPLICATION_STATUS_DESCRIPTION javaType=string/
result property=testResults
column={applicationKey=APPLICATION_KEY, processingKey=PR_PROCESSING_KEY}
select=getTestResultsForProcessingResult/
result property=application column=APPLICATION_KEY javaType=int
select=loadApplicationByPrimaryKey/
result property=processing column=PR_PROCESSING_KEY
javaType=int
select=loadProcessingSchedule/
/resultMap
select id=loadBatchResultsForDateRange parameterClass=DateRange
resultMap=BatchResultMap
select
PRO.PROCESSING_KEY,
PRO.PROCESS_DATE,
PRO.PRINT_DATE,
PRO.PROCESS_TYPE_KEY,
PT.DESCRIPTION as PROCESS_TYPE_DESCRIPTION,
PR.APPLICATION_KEY,
ASCD.APPLICATION_STATUS_KEY,
ASCD.DESCRIPTION as APPLICATION_STATUS_DESCRIPTION,
PR.PROCESSING_KEY as PR_PROCESSING_KEY
from
WM.USTP_PROCESSING PRO
join WM.USTP_PROCESS_TYPE_CD PT on PRO.PROCESS_TYPE_KEY =
PT.PROCESS_TYPE_KEY
left outer join WM.USTP_PROCESSING_RESULT PR on PR.PROCESSING_KEY
= PRO.PROCESSING_KEY
left outer join WM.USTP_APPLICATION_STATUS_CD ASCD on
ASCD.APPLICATION_STATUS_KEY = PR.APPLICATION_STATUS_KEY
where
PRO.PROCESS_DATE between #start# and (#end# + 1)
order by
PRO.PROCESSING_KEY desc
/select
public List loadByProcessingDateRange(DateRange aDateRange)
throws DataAccessException
{
return
[jira] Closed: (IBATIS-164) Oscache Properties
[ http://issues.apache.org/jira/browse/IBATIS-164?page=all ]
Sven Boden closed IBATIS-164:
-
Resolution: Won't Fix
Assign To: Sven Boden
Closed as won't fix as described in previous JIRA entry.
Oscache Properties
--
Key: IBATIS-164
URL: http://issues.apache.org/jira/browse/IBATIS-164
Project: iBatis for Java
Type: New Feature
Components: SQL Maps
Versions: 2.1.0
Reporter: marco Berri
Assignee: Sven Boden
Hi
in next Ibatis version, could you insert this line in OSCacheController.java
class?
public void configure(Properties props) {
this.CACHE = new GeneralCacheAdministrator(props);
}
Thanks a lot
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (IBATIS-204) Cache layer does no logging of puts, gets, flushes, or removals.
[ http://issues.apache.org/jira/browse/IBATIS-204?page=comments#action_12368873 ] Sven Boden commented on IBATIS-204: --- Attached a changed version of CacheModel that does logging. All comments are welcome. If no objections, check-in around March, 11th. Cache layer does no logging of puts, gets, flushes, or removals. Key: IBATIS-204 URL: http://issues.apache.org/jira/browse/IBATIS-204 Project: iBatis for Java Type: Improvement Components: SQL Maps Versions: 2.0.8, 2.0.9, 2.1.0, 2.0.9b, 2.1.5, 2.1.6, 2.2.5 Environment: All Reporter: michael campbell Priority: Minor Attachments: CacheModel.java The cache layer has no logging. Following is the code change I made (all cache mechanisms EXCEPT os-cache) to the cache code which suits my purposes. I tried to stay within the spirit of the existing logging, mimicing the output formats, etc. Released to the public domain. [...source snipped...] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (IBATIS-272) In com.ibatis.sqlmap.engine.execution.SQLExecutor class, line 390, the break should be return
[ http://issues.apache.org/jira/browse/IBATIS-272?page=all ] Sven Boden closed IBATIS-272: - Resolution: Duplicate Assign To: Sven Boden This is a duplicate of IBATIS-109, which is in SVN since last week. I would suggest to extract iBATIS from SVN and compile it. If it's not possible I can send you compiled SVN version. In com.ibatis.sqlmap.engine.execution.SQLExecutor class, line 390, the break should be return - Key: IBATIS-272 URL: http://issues.apache.org/jira/browse/IBATIS-272 Project: iBatis for Java Type: Bug Components: SQL Maps Versions: 2.1.7 Environment: DB2 8.2 on Windows, iBATIS 2.1.7, WebSphere 6.0 Reporter: david zhang Assignee: Sven Boden Priority: Critical When connecting to DB2, the DB2 will close the TYPE_FORWARD_ONLY (which is default) ResultSet automatically when reaching the end. So the SQLExecutor handleResults method throws SQLExeption out on line 397 for rs.next(). However, when line 389 reach the end of resultset, this method should return instead of break the for loop and continue to execute, this doesn't make sense. So the line 390 should be return instead of break. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (IBATIS-224) isNotNull node causes typehandler mappings in statement to fail
[ http://issues.apache.org/jira/browse/IBATIS-224?page=comments#action_12368182 ] Sven Boden commented on IBATIS-224: --- I added a patch to UnknownTypeHandler to IBATIS-224 (it will also solve IBATIS-210). This would solve enum support in Java 5+, and it would still be compatible with pre Java 5 environments (using reflection to get at new functionality). I think the change is acceptible, but I would like to get second opinions. We don't support Java 5 (1.5) yet, but it's going to come back anyway. isNotNull node causes typehandler mappings in statement to fail --- Key: IBATIS-224 URL: http://issues.apache.org/jira/browse/IBATIS-224 Project: iBatis for Java Type: Bug Components: SQL Maps Versions: 2.1.6 Environment: linux/java 1.5 Reporter: Reuben Firmin Priority: Critical Attachments: UnknownTypeHandler.java, ibatis-224_sven.zip, ibatis224.tar.gz Here's my insert statement. insert id=createDeployment parameterClass=deployment INSERT INTO Deployment ( environmentId, deploymentTypeId, deploymentStatusId, deploymentTime isNotNull property=threadCountOverride,threadCountOverride/isNotNull ) VALUES ( #environmentId#, #deploymentTypeId#, #deploymentStatusId#, #deploymentTime# isNotNull property=threadCountOverride,#threadCountOverride#/isNotNull ) selectKey resultClass=int keyProperty=deploymentId SELECT @@IDENTITY as value /selectKey /insert deploymentTypeId and deploymentStatusId are enums in the bean, mapped to values using custom type handlers. Without the isNotNull structure around threadCountOverride (which *is* nullable), the statement works. With the isNotNull, deploymentStatusId and deploymentTypeId are mapped to UnknownTypeHandler, and the insert fails to map the parameters from the bean. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (IBATIS-257) custom TypeHandlerCallback does not work - sometimes
[ http://issues.apache.org/jira/browse/IBATIS-257?page=all ] Sven Boden closed IBATIS-257: - Resolution: Invalid Closed as not a bug. custom TypeHandlerCallback does not work - sometimes Key: IBATIS-257 URL: http://issues.apache.org/jira/browse/IBATIS-257 Project: iBatis for Java Type: Bug Components: SQL Maps Versions: 2.1.7 Environment: WinXP; iBatis 2.1.7; Oracle 9i; JDK 1.4+ Reporter: Thomas Wagner The usage of a custom TypeHandlerCallback depends on the position of the column in the resultMap. If the previous colum has a value, all works fine. But if the value of the previous column is null, the mapping via a custom TypeHandlerCallback does not work. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (IBATIS-268) utilizing iBatis for data accessing in ANSC c++
[ http://issues.apache.org/jira/browse/IBATIS-268?page=all ] Sven Boden closed IBATIS-268: - Resolution: Invalid I'm going to close this JIRA as it's not related to iBATIS for Java, and there doesn't seem to be a lot of interest in an iBATIS for C++. utilizing iBatis for data accessing in ANSC c++ --- Key: IBATIS-268 URL: http://issues.apache.org/jira/browse/IBATIS-268 Project: iBatis for Java Type: New Feature Environment: redhat linux as4 Reporter: david_y_johnson i want to utilize iBatis's feature and function in c++ program -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (IBATIS-210) Enum within Collection is not mapped to custom TypeHandler
[ http://issues.apache.org/jira/browse/IBATIS-210?page=comments#action_12367856 ] Sven Boden commented on IBATIS-210: --- Test case for this also attached to IBATIS-224, it's the same problem. Generics are used and the TypeHandlerFactory can't map them as the name of the generic class are changed with each instantiation: $1, $2, $3, ... Enum within Collection is not mapped to custom TypeHandler -- Key: IBATIS-210 URL: http://issues.apache.org/jira/browse/IBATIS-210 Project: iBatis for Java Type: New Feature Components: SQL Maps Versions: 2.1.0 Environment: Linux/Spring/Resin/Jdk1.5 Reporter: Reuben Firmin Passing an Enum to Ibatis requires the declaration of a custom TypeHandler (see my comments here for my implementation: http://opensource2.atlassian.com/confluence/oss/display/IBATIS/How%20do%20I%20use%20a%20Custom%20Type%20Handler%20with%20complex%20property%20or%20Type%20Safe%20Enumeration) This works, except when the Enum is within a map or a list. That is, if I pass a list of Enum attributes to a statement, as a parameter, and attempt to iterate over them, they are mapped to UnknownTypeHandler. Similarly, when an Enum is passed as value in a HashMap as part of a parameter, it is also mapped to an UnknownTypeHandler. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (IBATIS-224) isNotNull node causes typehandler mappings in statement to fail
[
http://issues.apache.org/jira/browse/IBATIS-224?page=comments#action_12367864 ]
Sven Boden commented on IBATIS-224:
---
Following hack in UnknownTypeHandler will make it work for IBATIS-224/210...
but is not available until Java 5 (1.5), and it also has some implications for
generics so I would suggest to put this JIRA and IBATIS-210 on the back-burner
for now. It will require some more thought:
public void setParameter(PreparedStatement ps, int i, Object parameter,
String jdbcType)
throws SQLException {
Class searchClass = parameter.getClass().getEnclosingClass();
if ( searchClass == null ) {
searchClass = parameter.getClass();
}
TypeHandler handler = factory.getTypeHandler(searchClass, jdbcType);
handler.setParameter(ps, i, parameter, jdbcType);
}
isNotNull node causes typehandler mappings in statement to fail
---
Key: IBATIS-224
URL: http://issues.apache.org/jira/browse/IBATIS-224
Project: iBatis for Java
Type: Bug
Components: SQL Maps
Versions: 2.1.6
Environment: linux/java 1.5
Reporter: Reuben Firmin
Priority: Critical
Attachments: ibatis-224_sven.zip, ibatis224.tar.gz
Here's my insert statement.
insert id=createDeployment parameterClass=deployment
INSERT INTO Deployment (
environmentId, deploymentTypeId, deploymentStatusId,
deploymentTime
isNotNull
property=threadCountOverride,threadCountOverride/isNotNull
) VALUES (
#environmentId#, #deploymentTypeId#, #deploymentStatusId#,
#deploymentTime#
isNotNull
property=threadCountOverride,#threadCountOverride#/isNotNull
)
selectKey resultClass=int keyProperty=deploymentId
SELECT @@IDENTITY as value
/selectKey
/insert
deploymentTypeId and deploymentStatusId are enums in the bean, mapped to
values using custom type handlers. Without the isNotNull structure around
threadCountOverride (which *is* nullable), the statement works. With the
isNotNull, deploymentStatusId and deploymentTypeId are mapped to
UnknownTypeHandler, and the insert fails to map the parameters from the bean.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (IBATIS-270) Loading SqlMap XML to existing SqlMapClient
[ http://issues.apache.org/jira/browse/IBATIS-270?page=comments#action_12367675 ] Sven Boden commented on IBATIS-270: --- Looks easy to do, but I'm not in favor of putting this in iBATIS. At first sight this opens a can of worms. For the moment SqlMaps are order dependent (IBATIS-135), if you start loading maps via an API it's going to get much more complex. Then the change to load maps via an API. Then implementing IBATIS-208 to be able to reload. Loading SqlMap XML to existing SqlMapClient --- Key: IBATIS-270 URL: http://issues.apache.org/jira/browse/IBATIS-270 Project: iBatis for Java Type: New Feature Components: SQL Maps Environment: any Reporter: Richard Lin Priority: Minor Attachments: DynamicSqlMapExecutorDelegate.java Ability to dynamically load more SqlMap XML files not included in sqlmap-config.xml. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (IBATIS-109) Make PaginatedList work with IBM's broken JDBC driver
[ http://issues.apache.org/jira/browse/IBATIS-109?page=all ] Sven Boden closed IBATIS-109: - Fix Version: 2.2.0 Resolution: Fixed Fixed as in JIRA comments. - No additional testcases - I've been running the fix for a long time. It's a not so nice behaviour of IBM DB2, but calling next() after you know the cursor has reached the end may also not be that optimal. The fix works on all databases. I've tested with DB2, Oracle, HSQL. Thanks to Patrick Idem for the patch. Make PaginatedList work with IBM's broken JDBC driver - Key: IBATIS-109 URL: http://issues.apache.org/jira/browse/IBATIS-109 Project: iBatis for Java Type: Improvement Components: SQL Maps Versions: 2.0.8, 2.0.9, 2.1.0, 2.0.9b Environment: Any Java environment Reporter: Patrick Idem Priority: Minor Fix For: 2.2.0 Attachments: SqlExecutor.java Using DB2 database drivers cases an exception to be thrown when calling paginatedList.next() and the current page is the page before the last page. From what I can determine the PaginatedList class retrieves future records in order to determine if there are any more pages. An Exception will be caused in the following situation: A database table has 11 records. First issue a command to get a paginated list of all the records with a page size of 10: PaginatedList list = queryForPaginatedList(getAllRecords, null, 10) Since the paginated list reads ahead it will retrieve all 11 records and reach the end of the ResultSet. Now if we want to view the second page (which only consists of 1 record) we would then do the following: list.next() Now, calling list.next() should not have to go to the database since we had already reached the end of the ResultSet but it does! This is where the problem happens. DB2 drivers automatically close the ResultSet when you read in the last row so the ResultSet has been closed. I am suspecting that this problem is only serious when using DB2 drivers but it is still a problem. The paginated list object should be smart enough to know that there are no more results and not try to hit the database that last time. The actually DB2 exception that is thrown is the following: com.ibm.db2.jcc.a.SqlException: Invalid operation: result set closed -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (IBATIS-167) Improvements in SimpleDataSource
[ http://issues.apache.org/jira/browse/IBATIS-167?page=all ] Sven Boden closed IBATIS-167: - Fix Version: 2.2.0 Resolution: Fixed Fixed as in the JIRA comments: - No additional Junit testcases. To see it in action: * in the SqlMapConfig.xml of the testcases of iBATIS set Pool.TimeToWait to 0 and Pool.PingEnabled to true. And run the test cases. The PingQuery is wrong for at least 1 testcase, this shows the enhanced error messages. * in the SqlMapConfig.xml of the testcases of iBATIS set Pool.PingEnabled to true and remove Pool.PingQuery or set Pool.PingQuery to an empty string. Run the test cases. This shows what happens when you enable pinging without a proper query. - I have been running this patch for a long time. Improvements in SimpleDataSource Key: IBATIS-167 URL: http://issues.apache.org/jira/browse/IBATIS-167 Project: iBatis for Java Type: Improvement Components: SQL Maps Versions: 2.1.0, 2.0.9b, 2.0.9, 2.0.8 Environment: All Reporter: Sven Boden Priority: Trivial Fix For: 2.2.0 Attachments: SimpleDataSource.java 1) With some small changes in SimpleDataSource problems as described in IBATIS-158 would occurr much less. 2) Requested by Clinton: The biggest improvement I'd like to make is removal of the exclusive Properties based configuration. I'd rather have a JavaBean style API for configuration, which could potentually use a Properties file still, but with properties that match exact JavaBeans properties for configuration. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (IBATIS-230) Warn when two ids of a sql tag are identical
[ http://issues.apache.org/jira/browse/IBATIS-230?page=all ] Sven Boden closed IBATIS-230: - Fix Version: 2.2.0 Resolution: Fixed Fixed as in JIRA comments: - no additional test cases - when 2 ids of an SQL tag are the same a log warning is issued, no exception is thrown. If it happens in development you get notified (if you run with debugging set high enough), in production it will happily keep on running. Change is in file SqlMapParser.java Warn when two ids of a sql tag are identical -- Key: IBATIS-230 URL: http://issues.apache.org/jira/browse/IBATIS-230 Project: iBatis for Java Type: Improvement Components: SQL Maps Versions: 2.1.6 Environment: Windows XP, JDK 1.4.2, Eclipse 3.1 Reporter: Thomas Noirez Priority: Minor Fix For: 2.2.0 Attachments: SqlMapParser.java When they are two sql tags with the same id, the last read is the one ! but may be a warning will be usefull to say that id already exists... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (IBATIS-266) when a roll back occurs in stored procedure. The status is not being handled by IBATIS causing it to crash.
[ http://issues.apache.org/jira/browse/IBATIS-266?page=all ] Sven Boden closed IBATIS-266: - Resolution: Invalid Closed as not a problem in iBATIS. when a roll back occurs in stored procedure. The status is not being handled by IBATIS causing it to crash. Key: IBATIS-266 URL: http://issues.apache.org/jira/browse/IBATIS-266 Project: iBatis for Java Type: Bug Versions: 2.1.5 Environment: Websphere Studio Application Developer running on Windows XP . Stored procedure being called is in DB2. Reporter: Mohamed Asad IBATIS does not handle SP Status returned back from the Stored procedure when a roll back is occured The rollback command is in the StoredProcedure and not in the Java Code. When the Stored procedure is rolled back in DB2 . The iBATIS code just crashes. I tried calling the Same SP from websphere tool and it did recieve a SPStatus. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (IBATIS-261) CLONE -The method executor.executeBatch() always returns 0.
[ http://issues.apache.org/jira/browse/IBATIS-261?page=all ]
Sven Boden closed IBATIS-261:
-
Fix Version: 2.2.0
Resolution: Invalid
Assign To: Sven Boden
This is not a bug in iBATIS, so I'm closing the JIRA. I would suggest to use
the dev mailing list for further discussion... if required.
I made small testcase with Oracle to simulate the problem, the easiest for you
would be to put a breakpoint on the method executeBatch() in SqlExecutor and
step through that method (and also going into batch.executeBatch()).
What you will detect in there is that the updates/inserts get executed properly
but the return array of ints of executeBatch will contain all -2's, which get
translated to 0 and added up... so you will always get 0 back upon successful
execution.
The reason is Oracle (not the JDBC drivers, Oracle). From the Oracle manuals:
For a prepared statement batch, it is not possible to know the number of rows
affected in the database by each individual statement in the batch. Therefore,
all array elements have a value of -2. According to the JDBC 2.0 specification,
a value of -2 indicates that the operation was successful but the number of
rows affected is unknown., hence your problem with the row count.
Oracle has decided not to support the row count in a batch for
PreparedStatements. iBATIS uses PreparedStatements, even if you use all $$
notation (PreparedStatement without parameters) and that's why you get a 0 row
count. The JDBC spec leaves it open, Oracle took the easy way out in this case,
HSQL implemented it.
Just on a side note:
- Oracle also does not support batch processing for non-PreparedStatements (you
can put them in a batch, but they are sent 1 by 1 to the database server
without batching).
- You do need PreparedStatements with properly binded arguments for Oracle
unless you want to experience severe performance and scalability problems.
Sven
CLONE -The method executor.executeBatch() always returns 0.
---
Key: IBATIS-261
URL: http://issues.apache.org/jira/browse/IBATIS-261
Project: iBatis for Java
Type: Bug
Components: SQL Maps
Versions: 2.1.0
Environment: SUN JVM 1.4.2 On Windows
Reporter: Arne Burmeister
Assignee: Sven Boden
Fix For: 2.2.0
I am using Sql Maps 2.1.5 with Spring 1.2.4.
I have a method as following.
I want to get the number of rows updated in the batch .
But it always returns 0.
public int insertBatchError(final List batchErrorList) {
Integer count = (Integer) getSqlMapClientTemplate().execute(new
SqlMapClientCallback() {
public Object doInSqlMapClient(SqlMapExecutor executor) throws
SQLException {
executor.startBatch();
for (int i = 0; i batchErrorList.size(); i++) {
BatchErrorDTO batchErrorDto = (BatchErrorDTO)
batchErrorList.get(i);
executor.update(insertBatchError, batchErrorDto);
}
int count = executor.executeBatch();
return new Integer(count);
}
});
return count.intValue();
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (IBATIS-264) Include with parameter
[ http://issues.apache.org/jira/browse/IBATIS-264?page=comments#action_12367175 ] Sven Boden commented on IBATIS-264: --- Currently the sql/include are pretty static, so it's not really a peanut change. Your proposal takes care of 1 argument, how would you handle multiple arguments? Personally I don't see a huge benefit in the proposal the way I use includes now: 1) When including columns you can chose your table aliases so you can make sure different queries using the same columns use the same table aliases (in the select and in the sql snippet). And how many times are you going to have a situation in which you have the same columns in 2 different tables using different aliases. 2) When putting a query starting from the from part in an sql include and having different columns in different selects but including the same base query I also don't see a huge benefit for arguments. Include with parameter -- Key: IBATIS-264 URL: http://issues.apache.org/jira/browse/IBATIS-264 Project: iBatis for Java Type: Improvement Components: SQL Maps Versions: 2.1.7 Reporter: Nils Winkler Priority: Minor I have the following problem: I include the same SQL snippet from multiple select statements, some of them for completely unrelated tables. This is done because these tables contain quite a few columns with the same names in both tables. sql id=inc name, value, foo, bar /sql select id=loadA select id, include refid=inc / from A /select select id=loadB select id, include refid=inc / from B /select When including the list of columns, it would be quite handy to add a parameter to the include, for example to set a table alias in case I have a join between tables: select id=loadA select a.id, b.id, include refid=inc / from A a inner join B b on (b.id = a.id) where b.baz = #baz# /select In the above query, name, value etc are no longer unique in the query, most of the time you end up with the wrong values. It would be great if I would be able to pass in a parameter to the include, e.g.: select id=loadA select a.id, b.id, include refid=inc param=a./ from A a inner join B b on (b.id = a.id) where b.baz = #baz# /select so I could have the SQL snippet defined like this: sql id=inc $param$name, $param$value, $param$foo, $param$bar /sql This way, all of the statements would still work and I could make sure that the correct columns are used in each case. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (IBATIS-266) when a roll back occurs in stored procedure. The status is not being handled by IBATIS causing it to crash.
[ http://issues.apache.org/jira/browse/IBATIS-266?page=comments#action_12367244 ] Sven Boden commented on IBATIS-266: --- Can you attach the errors you get from iBatis (the complete stacktrace) to the JIRA. Other points: 1) It's pretty exceptional doing commits or rollbacks in stored procedures as it limits the reusability of your stored procedures. 2) The problem you're seeing is probably a DB2 driver problem. When DB2 does a rollback it also closes all ResultSets in the same unit of work (a commit e.g. will not). I vaguely remember a trick in DB2 using 2 Connections to get work done without DB2 bailing out, but that's not going make it in iBATIS. 3) Are you handling the exception possibly returned from the call to the stored procedure? when a roll back occurs in stored procedure. The status is not being handled by IBATIS causing it to crash. Key: IBATIS-266 URL: http://issues.apache.org/jira/browse/IBATIS-266 Project: iBatis for Java Type: Bug Versions: 2.1.5 Environment: Websphere Studio Application Developer running on Windows XP . Stored procedure being called is in DB2. Reporter: Mohamed Asad IBATIS does not handle SP Status returned back from the Stored procedure when a roll back is occured The rollback command is in the StoredProcedure and not in the Java Code. When the Stored procedure is rolled back in DB2 . The iBATIS code just crashes. I tried calling the Same SP from websphere tool and it did recieve a SPStatus. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (IBATIS-230) Warn when two ids of a sql tag are identical
[ http://issues.apache.org/jira/browse/IBATIS-230?page=comments#action_12367278 ] Sven Boden commented on IBATIS-230: --- This is also something I would like to fix around the end of the week, if no complaints: When you have 2 sql includes in an SqlMap with the same id you currently don't get an error message, and the last one takes precedence. This can lead to some unexpected results. i would like to throw an exception on duplicate id's. The exception would be different behaviour as currently is the case, but if someone would be using duplicate sql they would see it the moment they start up with the changes, and it requires only SqlMap changes to fix it, no application source code changes. Warn when two ids of a sql tag are identical -- Key: IBATIS-230 URL: http://issues.apache.org/jira/browse/IBATIS-230 Project: iBatis for Java Type: Improvement Components: SQL Maps Versions: 2.1.6 Environment: Windows XP, JDK 1.4.2, Eclipse 3.1 Reporter: Thomas Noirez Priority: Minor Attachments: SqlMapParser.java When they are two sql tags with the same id, the last read is the one ! but may be a warning will be usefull to say that id already exists... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (IBATIS-267) utilizing iBatis
[ http://issues.apache.org/jira/browse/IBATIS-267?page=all ] Sven Boden closed IBATIS-267: - Resolution: Duplicate Duplicate to IBATIS-268 utilizing iBatis Key: IBATIS-267 URL: http://issues.apache.org/jira/browse/IBATIS-267 Project: iBatis for Java Type: New Feature Reporter: david_y_johnson -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (IBATIS-230) Warn when two ids of a sql tag are identical
[ http://issues.apache.org/jira/browse/IBATIS-230?page=comments#action_12367313 ] Sven Boden commented on IBATIS-230: --- We may settle for a log message only then (without configuration options). Reason I originally didn't want log messages is that logging is currently not used in SqlMapParser, we can still upgrade it later to an exception. Warn when two ids of a sql tag are identical -- Key: IBATIS-230 URL: http://issues.apache.org/jira/browse/IBATIS-230 Project: iBatis for Java Type: Improvement Components: SQL Maps Versions: 2.1.6 Environment: Windows XP, JDK 1.4.2, Eclipse 3.1 Reporter: Thomas Noirez Priority: Minor Attachments: SqlMapParser.java When they are two sql tags with the same id, the last read is the one ! but may be a warning will be usefull to say that id already exists... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (IBATIS-109) Make PaginatedList work with IBM's broken JDBC driver
[ http://issues.apache.org/jira/browse/IBATIS-109?page=comments#action_12367021 ] Sven Boden commented on IBATIS-109: --- I would like to implement the fix for JIRA IBATIS-109... checkin around February 24 unless someone has objections. Right now the handleResults() method in SQLExecutor will when it finds the end of the cursor while skipping rows break out of the skip loop, try to read the next row and start processing rows. When it already reached end of cursor in the skip loop this read will of course fail, nothing will be processed and the method will be exited. (however DB2 will cause an exception to be thrown on the read after the loop, as DB2 closes the cursor upon reaching end of cursor). The fix replaces the break from the skip loop with a return (so that the read after the loop is not executed in case the end of cursor has been reached while skipping). For non-DB2 databases it's also ok to stop processing then: the end of cursor has been reached and no processing will occur anyway. I've been running this patch in iBATIS for a couple of months without problems, and all of the unit test cases still work. It's also only a 1 line change. Make PaginatedList work with IBM's broken JDBC driver - Key: IBATIS-109 URL: http://issues.apache.org/jira/browse/IBATIS-109 Project: iBatis for Java Type: Improvement Components: SQL Maps Versions: 2.0.8, 2.0.9, 2.1.0, 2.0.9b Environment: Any Java environment Reporter: Patrick Idem Priority: Minor Attachments: SqlExecutor.java Using DB2 database drivers cases an exception to be thrown when calling paginatedList.next() and the current page is the page before the last page. From what I can determine the PaginatedList class retrieves future records in order to determine if there are any more pages. An Exception will be caused in the following situation: A database table has 11 records. First issue a command to get a paginated list of all the records with a page size of 10: PaginatedList list = queryForPaginatedList(getAllRecords, null, 10) Since the paginated list reads ahead it will retrieve all 11 records and reach the end of the ResultSet. Now if we want to view the second page (which only consists of 1 record) we would then do the following: list.next() Now, calling list.next() should not have to go to the database since we had already reached the end of the ResultSet but it does! This is where the problem happens. DB2 drivers automatically close the ResultSet when you read in the last row so the ResultSet has been closed. I am suspecting that this problem is only serious when using DB2 drivers but it is still a problem. The paginated list object should be smart enough to know that there are no more results and not try to hit the database that last time. The actually DB2 exception that is thrown is the following: com.ibm.db2.jcc.a.SqlException: Invalid operation: result set closed -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (IBATIS-161) Finer Grain Control on settings
[ http://issues.apache.org/jira/browse/IBATIS-161?page=all ] Sven Boden closed IBATIS-161: - Resolution: Duplicate This is a duplicate of IBATIS-246, or the other way around. As IBATIS-246 is newer I will attach the comment of this one to IBATIS-246. Finer Grain Control on settings --- Key: IBATIS-161 URL: http://issues.apache.org/jira/browse/IBATIS-161 Project: iBatis for Java Type: Improvement Components: SQL Maps Versions: 2.1.0 Reporter: Stephane Bailliez Priority: Minor Following my post in the dev list. It would probably be interesting to have fine-grained control over the lazy-loading. For instance, having a per-statement lazy-loading flag where dependent requests (like in the case of n+1 selects) would inherit this flag. I came over it after discovering that cglib-enhanced classes are not serializable, which make sense due to lazy-loading. You could need it for the following case: You may know, that your relationships are not in the form 1:bazillion but more like 1:4 (replace 4 by your favorite 'less than 10' number) with very lightweights objects , thus the need to potentially be able to disable cglib enhanced relations. To workaround this, you can: 1) disable application-wide lazy loading via settings/ (big side-effect) 2) implements your own serialization mechanism by basically cloning the relations. (code clutter) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (IBATIS-243) handling custom tables with custom objects returned from stored procedure
[ http://issues.apache.org/jira/browse/IBATIS-243?page=all ]
Sven Boden closed IBATIS-243:
-
Resolution: Invalid
Assign To: Sven Boden
This is a support question.
The first response would be: how do you this in JDBC?
The second response would be that iBATIS doesn't support it, and will probably
not support it.
For a third response: have a look at
http://asktom.oracle.com/pls/ask/f?p=4950:8:F4950_P8_DISPLAYID:10271519764319
in which they don't advise to use object types in Java.
For a fourth and final response: O'Reilly has a book called Java Programming
with Oracle JDBC in which in Chapter 4 they completely explain what you want
to do (in JDBC) and where you will also see it's complexer than the
corresponding relational approach.
Sven
handling custom tables with custom objects returned from stored procedure
-
Key: IBATIS-243
URL: http://issues.apache.org/jira/browse/IBATIS-243
Project: iBatis for Java
Type: Improvement
Components: SQL Maps
Versions: 2.1.6
Environment: Windows XP ,
Oracle 10g
java 1.4
Reporter: Smaranda Tudor
Assignee: Sven Boden
Priority: Critical
Hi,
I have a problem with iBatis. Because some processings, which need to be done
in the database, I have to handle a strange returned datatype. Here is the
object structure (as sample, just a smaller than the original):
CREATE OR REPLACE
TYPE FACS_OBJ AS OBJECT
(
ID NUMBER(12),
NAME VARCHAR2(80),
CODE VARCHAR2(12),
)
and
CREATE OR REPLACE
type FACS_TABLE as table of FACS_OBJ;
As you can see there is about TABLE OF custom objects. The procedure has only
an out parameter of this kind of type. My mapping looks like the next
sequence:
parameterMap class=map id=facs_ids
parameter property=outParameter jdbcType=ARRAY
typeName=FACS_TABLE
mode=OUT
typeHandler=ArrayTypeHandlerCallback /
/parameterMap
procedure id=testSpecialType parameterMap=facs_ids
![CDATA[
{ call PAC_CR_SECURITY.testSpecialType(?) }
]]
/procedure
My handler does nothing special than override the getResult function:
public Object getResult(ResultGetter rg) throws SQLException {
if (rg.wasNull()) {
return null;
}
Array arr = rg.getArray();
if (arr == null) {
return default_result;
}
ResultSet rs = arr.getResultSet();
if (rs == null) {
return default_result;
}
List results = new ArrayList();
while (rs.next()) {
Object result = rs.getObject(2);
if (log.isDebugEnabled()) {
log.debug(result classname: + result.getClass().getName());
}
results.add((Struct)result);
}
return results;
}
My problem is next : the type of inner objects is not transparent to the java
application. The struct type is quite difficult to process. How could I
handle the returned type in this situation. This object is a simple one
because it could contain another lists as members.
Thanks
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (IBATIS-164) Oscache Properties
[
http://issues.apache.org/jira/browse/IBATIS-164?page=comments#action_12367157 ]
Sven Boden commented on IBATIS-164:
---
Making it possible to create an OScache with Properties seems like a sensible
thing. Currently the configure is empty and properties are ignored when passed
in. Checkin will follow soon.
Oscache Properties
--
Key: IBATIS-164
URL: http://issues.apache.org/jira/browse/IBATIS-164
Project: iBatis for Java
Type: New Feature
Components: SQL Maps
Versions: 2.1.0
Reporter: marco Berri
Hi
in next Ibatis version, could you insert this line in OSCacheController.java
class?
public void configure(Properties props) {
this.CACHE = new GeneralCacheAdministrator(props);
}
Thanks a lot
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (IBATIS-167) Improvements in SimpleDataSource
[ http://issues.apache.org/jira/browse/IBATIS-167?page=comments#action_12366960 ] Sven Boden commented on IBATIS-167: --- Anyone thoughts or objections against the changes in IBATIS-167. What I would change: - When pinging of the pool is enabled but no ping query is defined in the properties thrown an exception in initialize(). It's better to sink the boat in port than at open sea. If no exception is thrown problems would start occuring later on anyway. - In pingConnection(): When a connection check throws an exception include the message of the exception. When the ping query fails report the ping query and the corresponding SQL error message as log error, this should give most people who have this problem an aha feeling. - Change error message: Error accessing SimplePooledConnection. Connection has been invalidated (probably released back to the pool). Leave of the released back to the pool part... in most cases this explanation will be wrong and will cause confusion (as in IBATIS-158). I plan to check in the changes around February 24 unless someone reacts. Regards, Sven Improvements in SimpleDataSource Key: IBATIS-167 URL: http://issues.apache.org/jira/browse/IBATIS-167 Project: iBatis for Java Type: Improvement Components: SQL Maps Versions: 2.0.8, 2.0.9, 2.1.0, 2.0.9b Environment: All Reporter: Sven Boden Priority: Trivial Attachments: SimpleDataSource.java 1) With some small changes in SimpleDataSource problems as described in IBATIS-158 would occurr much less. 2) Requested by Clinton: The biggest improvement I'd like to make is removal of the exclusive Properties based configuration. I'd rather have a JavaBean style API for configuration, which could potentually use a Properties file still, but with properties that match exact JavaBeans properties for configuration. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (IBATIS-160) Pass custom EntityResolver to SqlMapClientBuilder
[ http://issues.apache.org/jira/browse/IBATIS-160?page=all ] Sven Boden closed IBATIS-160: - Duplicate of IBATIS-140 Pass custom EntityResolver to SqlMapClientBuilder - Key: IBATIS-160 URL: http://issues.apache.org/jira/browse/IBATIS-160 Project: iBatis for Java Type: New Feature Components: SQL Maps Reporter: nilesh Assignee: Sven Boden Is there a way to plugin own EntityResolver to SqlMapClientBuilder before it parse sql maps? The reason I'm looking for this is to avoid resolving iBatis DTDs over the internet and rather resolve those using iBatis jar files. My environment is setup with JDom parser. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (IBATIS-150) Requirement and benefit of groupBy attribute is not clear in SQL Maps Dev Guide
[ http://issues.apache.org/jira/browse/IBATIS-150?page=all ] Sven Boden closed IBATIS-150: - Fix Version: 2.2.0 Resolution: Fixed Assign To: Sven Boden OpenOffice document changed. PDF regenerated. The PDF is not yet available on the website, but can be downloaded at: http://svn.apache.org/repos/asf/ibatis/trunk/java/docs/ Requirement and benefit of groupBy attribute is not clear in SQL Maps Dev Guide --- Key: IBATIS-150 URL: http://issues.apache.org/jira/browse/IBATIS-150 Project: iBatis for Java Type: Improvement Components: Documentation Reporter: Ersin Er Assignee: Sven Boden Priority: Minor Fix For: 2.2.0 Attachments: iBATIS-SqlMaps-2.sxw The example on page 28 of SQL Maps Developer Guide uses groupBy attribute's requirement and benefit in the SQLMap XML file. The requirement and benefit of this attribute is not clear. There are two main reasons for this issue: 1) The SQL statement given as an example also uses groupBy (which is really not related to the one usen as an XML attribute.) 2) The groupBy attribute's value is given as the name of the DB table column which also same as the Java class' preperty name. Solution: 1) A simpler query may be provided so that groupBy attributes requirement and benefits becomes clearer. 2) Column name and property name may be selected to be different so that it becomes clear that groupBy attribute takes a property name as the value. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (IBATIS-260) Hash conflict with groupBy resultMaps
[ http://issues.apache.org/jira/browse/IBATIS-260?page=comments#action_12366929 ] Sven Boden commented on IBATIS-260: --- Fix that solves IBATIS-260 attached to JIRA, not checked in to SVN yet. After someone else verifies the fix and my local unit test case for it is cleaned up, I will check it in. Hash conflict with groupBy resultMaps - Key: IBATIS-260 URL: http://issues.apache.org/jira/browse/IBATIS-260 Project: iBatis for Java Type: Bug Components: SQL Maps Versions: 2.1.7 Environment: iBatis 2.1.7 MacOS 10.4.4 MySQL 5.0.18 Reporter: Stuart Piltch Priority: Minor Attachments: ibatis.zip I've found another issue that's similar to the one reported (by me) and fixed (by Clinton) back in Jira iBatis-79 I have pretty much the same setup as last time, but the problem now is: 1) If there are nested groups, such as topic_category.name -- topic.name -- count(*) 2) If the same 2nd level name exists in more than one 1st level, such as the same topic.name existing in more than one topic_category then only one 2nd level name (topic.name) is used as the hash. Only the last (or the first - haven't really checked that part) assignment is loaded. In my example, three separate topic categories have the same topic name and only one of the names gets assigned in the resultMap. The raw SQL query correctly shows counts in all three categories. Changing the topic names in the db slightly makes the problem go away. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (IBATIS-249) Race conditions in Throttle lead to thread blockage popping items from ThrottledPools under stress
[ http://issues.apache.org/jira/browse/IBATIS-249?page=all ] Sven Boden closed IBATIS-249: - Fix Version: 2.2.0 Resolution: Fixed Assign To: Sven Boden Thanks for the IBATIS-249 patch Jonathan, changes checked in: - Verified by at least 2 other people - I played a little bit with it - Logically the changes look correct - No unit test case as it's difficult to simulate Race conditions in Throttle lead to thread blockage popping items from ThrottledPools under stress -- Key: IBATIS-249 URL: http://issues.apache.org/jira/browse/IBATIS-249 Project: iBatis for Java Type: Bug Components: SQL Maps Versions: 2.1.7 Reporter: Jonathan Burstein Assignee: Sven Boden Fix For: 2.2.0 Attachments: IBATIS-249.diff com.ibatis.common.util.Throttle.increment contains a synchronization error. Currently, when a waiting thread returns from LOCK.wait it will increment count and return without checking that count is below limit. There are a number of situations where LOCK.wait can complete but the count will not be less than the limit: 1) The wait was interrupted 2) There was a spurious thread wakeup 3) Another thread obtained the lock between the time LOCK.notify was called (by a thread calling decrement) and the wait returned. The fix here is to re-check the value of count after exiting the wait (using a while loop). A small amount of extra logic is necessary to satisfy maxWait properly. ThrottledPool.pop attempts to work around these race conditions by catching swallowing all exceptions from throttle.increment and pool.remove(0) and looping until an item is obtained. Since the increment call is within the loop this logic can lead to multiple increments with no corresponding decrements. Note that an IndexOutOfBound exception from pool.remove(0) is an artifact of the bug in Throttle.increment -- this could never occur if Throttle behaved correctly. This routine should simple call throttle.increment and pool.remove(0). It should most certainly not swallow exceptions. Finally, ThrottledPool.push incorrectly calls throttle.decrement if the parameter is invalid (null or of an incorrect type). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (IBATIS-258) Invalid DOCTYPE instruction in example SQL Map file in documentation bundle.
[ http://issues.apache.org/jira/browse/IBATIS-258?page=all ] Sven Boden closed IBATIS-258: - Fix Version: 2.2.0 Resolution: Fixed Assign To: Sven Boden Fixed in SVN. Replaced iBATIS.com by ibatis.apache.org and using the correct type of DTD in the xml files. DOCTYPE references in the OpenOffice documentation will be done later. Invalid DOCTYPE instruction in example SQL Map file in documentation bundle. Key: IBATIS-258 URL: http://issues.apache.org/jira/browse/IBATIS-258 Project: iBatis for Java Type: Bug Components: Documentation Versions: 2.1.7 Reporter: Mark Tye Assignee: Sven Boden Priority: Minor Fix For: 2.2.0 Attachments: sql-map.txt.diff The user and developer Javadoc bundles (user-javadoc.zip and dev-javadoc.zip) both contain an example SQL Map File named sql-map.txt, located at /com/ibatis/sqlmap/client, that is referenced in the API documentation. (Specifically, the class-level Javadoc for the com.ibatis.sqlmap.client.SqlMapClientBuilder links to sql-map.txt with an anchor titled An SQL Map File.) This sql-map.txt file contains an error. Lines 2 through 4 of the file contain a DOCTYPE instruction for the sqlMap element that references the DTD located at http://www.ibatis.com/dtd/sql-map-2.dtd;. Unfortunately, the unique PUBLIC name associated with this DTD is incorrect. The PUBLIC name specified in the DOCTYPE instruction is: -//iBATIS.com//DTD SQL Map Config 2.0//EN However, that unique name is associated with the SQL Map *Config* DTD, not with the SQL Map DTD. I believe the correct name that should be used is: -//iBATIS.com//DTD SQL Map 2.0//EN The usage of the same unique name for two different DTDs causes problems for certain validating parsers. (Crimson, in particular.) When a SQL Map Config is parsed, the SQL Map Config DTD is associated with the unique name specified in the DOCTYPE instruction. When the same parser subsequently tries to validate a SQL Map that uses the same unique name, it applies the SQL Map Config DTD to the SQL Map file. This results in a validation error, because the SQL Map Config DTD declares that the sqlMap element must be EMPTY, even though the SQL Map DTD allows nested content. The error in the sql-map.txt file causes problems for developers who use the file as a template to configure their own SQL Maps. If they don't notice the very subtle error in the DOCTYPE instruction, their attempts to build a SqlMapClient will result in cryptic SAXParseExceptions that contain no hint as to what the underlying problem is. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (IBATIS-258) Invalid DOCTYPE instruction in example SQL Map file in documentation bundle.
[ http://issues.apache.org/jira/browse/IBATIS-258?page=comments#action_12366595 ] Sven Boden commented on IBATIS-258: --- Thanks for finding that. By the way the current DOCTYPES are: !DOCTYPE sqlMapConfig PUBLIC -//ibatis.apache.org//DTD SQL Map Config 2.0//EN http://ibatis.apache.org/dtd/sql-map-config-2.dtd; !DOCTYPE sqlMap PUBLIC -//ibatis.apache.org//DTD SQL Map 2.0//EN http://ibatis.apache.org/dtd/sql-map-2.dtd; !DOCTYPE dao PUBLIC -//ibatis.apache.org//DTD DAO Configuration 2.0//EN http://ibatis.apache.org/dtd/dao-2.dtd; So using ibatis.apache.org instead of ibatis.com, so maybe this JIRA is also a good hook to sweep over source coude and documentation and change the DOCTYPE everywhere. Invalid DOCTYPE instruction in example SQL Map file in documentation bundle. Key: IBATIS-258 URL: http://issues.apache.org/jira/browse/IBATIS-258 Project: iBatis for Java Type: Bug Components: Documentation Versions: 2.1.7 Reporter: Mark Tye Priority: Minor Attachments: sql-map.txt.diff The user and developer Javadoc bundles (user-javadoc.zip and dev-javadoc.zip) both contain an example SQL Map File named sql-map.txt, located at /com/ibatis/sqlmap/client, that is referenced in the API documentation. (Specifically, the class-level Javadoc for the com.ibatis.sqlmap.client.SqlMapClientBuilder links to sql-map.txt with an anchor titled An SQL Map File.) This sql-map.txt file contains an error. Lines 2 through 4 of the file contain a DOCTYPE instruction for the sqlMap element that references the DTD located at http://www.ibatis.com/dtd/sql-map-2.dtd;. Unfortunately, the unique PUBLIC name associated with this DTD is incorrect. The PUBLIC name specified in the DOCTYPE instruction is: -//iBATIS.com//DTD SQL Map Config 2.0//EN However, that unique name is associated with the SQL Map *Config* DTD, not with the SQL Map DTD. I believe the correct name that should be used is: -//iBATIS.com//DTD SQL Map 2.0//EN The usage of the same unique name for two different DTDs causes problems for certain validating parsers. (Crimson, in particular.) When a SQL Map Config is parsed, the SQL Map Config DTD is associated with the unique name specified in the DOCTYPE instruction. When the same parser subsequently tries to validate a SQL Map that uses the same unique name, it applies the SQL Map Config DTD to the SQL Map file. This results in a validation error, because the SQL Map Config DTD declares that the sqlMap element must be EMPTY, even though the SQL Map DTD allows nested content. The error in the sql-map.txt file causes problems for developers who use the file as a template to configure their own SQL Maps. If they don't notice the very subtle error in the DOCTYPE instruction, their attempts to build a SqlMapClient will result in cryptic SAXParseExceptions that contain no hint as to what the underlying problem is. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (IBATIS-250) CLONE -SELECT statement returns unexpected result when 'groupBy' and 'nullValue' are specified in resultMaps.
[ http://issues.apache.org/jira/browse/IBATIS-250?page=all ]
Sven Boden closed IBATIS-250:
-
Fix Version: 2.2.0
(was: 2.1.7)
Resolution: Fixed
Assign To: Sven Boden (was: Clinton Begin)
Fix for JIRA IBATIS-250 checked in in SVN.
Files changed:
com.ibatis.sqlmap.engine.mapping.result.BasicResultMap
java\test\mapper\mapper2\test\com\ibatis\sqlmap\maps\RepeatingGroupMapping.xml
java\test\mapper\mapper2\test\com\ibatis\sqlmap\RepeatingGroupMappingTest.java
Impact:
Normally when using a groupby in a ResultMap and all values of a child object
are empty no child object is created.
Before this fix if you used a groupby in combination with a nullValue attribute
an almost empty child object would be created in the normal case above (the
nullValue attribute would clash with the check for null values). After the fix
the behaviour of groupby/nullValue is the same as in the normal case: no child
object is created if all its properties are null.
Tests:
- Verified by me
- Verified by 3rd party
- Added unit testcase and old testcases still work
CLONE -SELECT statement returns unexpected result when 'groupBy' and
'nullValue' are specified in resultMaps.
-
Key: IBATIS-250
URL: http://issues.apache.org/jira/browse/IBATIS-250
Project: iBatis for Java
Type: Bug
Components: SQL Maps
Versions: 2.1.5
Environment: PowerMac G5 1.8GHz dual, 2.25GB RAM, Mac OS X 10.4.2
Using SqlMaps from tomcat via spring framework.
Reporter: Iwao AVE!
Assignee: Sven Boden
Fix For: 2.2.0
Attachments: jira_250.zip
[Preparation]
-- Database
CREATE TABLE parent ( parentId, parentName );
CREATE TABLE child ( childId, parentId, childName, childAge );
INSERT INTO parent ( parentId, parentName ) VALUES ( 1, 'Mr Parent' );
-- Java classes.
public class Parent
{
private int parentId;
private String parentName;
private List childList;
// accessor methods...
}
public class Child
{
private int childId;
private String childName;
private int childAge;
// accessor methods...
}
--SqlMap.
sqlMap namespace=Family
resultMap id=parentResult class=Parent groupBy=parentId
result property=parentId column=parentId/
result property=parentName column=parentName/
result property=childList resultMap=Family.childResult/
/resultMap
resultMap id=childResult class=Child
result property=childId column=childId/
result property=childName column=childName/
result property=childAge column=childAge nullValue=0/
/resultMap
select id=getParent resultMap=parentResult parameterClass=int
SELECT
parent.parentId, parent.parentName,
child.childId, child.childName, child.childAge
FROM parent
LEFT JOIN child ON parent.parentId = child.parentId
WHERE
parent.parentId = #value#
/select
/sqlMap
--
[Test]
Executing statement getParent with parameter '1'.
[Expected result]
Query returns 1 'Parent' object and 'childList' property of it is empty
(doesn't mean null).
[Actual result]
The 'childList' property of the returned 'Parent' contains 1 'Child' object.
[Additional information]
If 'nullValue' is not specified in 'childResult', it works as expected.
But this, of course, causes an error if there is a row in the 'child' table
and the 'childAge' column is null.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Closed: (IBATIS-217) I would like to see korean document on iBATIS website's document page
[ http://issues.apache.org/jira/browse/IBATIS-217?page=all ] Sven Boden closed IBATIS-217: - Fix Version: 2.2.0 Resolution: Fixed Assign To: Sven Boden Korean iBatis manual exists at http://ibatis.apache.org/javadownloads.html together with the rest of the downloads. Considered to be fixed. I would like to see korean document on iBATIS website's document page - Key: IBATIS-217 URL: http://issues.apache.org/jira/browse/IBATIS-217 Project: iBatis for Java Type: Wish Components: Documentation Reporter: DongGuk Lee Assignee: Sven Boden Fix For: 2.2.0 Korean SQLMaps users can't look for korean SQLMaps document on following URL. http://ibatis.apache.org/downloads.html I would like to see korean SQLMaps document on iBATIS website's document page please upload korean document to http://ibatis.apache.org/downloads.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (IBATIS-253) Closing of resultset Cursor
[ http://issues.apache.org/jira/browse/IBATIS-253?page=all ] Sven Boden closed IBATIS-253: - Resolution: Invalid Assign To: Sven Boden support question, refer to the mailing list iBATIS for Java mailing list at http://ibatis.apache.org/mailinglists.html Closing of resultset Cursor --- Key: IBATIS-253 URL: http://issues.apache.org/jira/browse/IBATIS-253 Project: iBatis for Java Type: Bug Reporter: Shiuli Deb Assignee: Sven Boden With reference to my Previous isuue regarding the closing of resultset cursor,I am using Parameter map and result map using queryForList Method.I do not know how and where the resultset cursor gets closed.Please Suggest some possiblities. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (IBATIS-254) Closing of resultset Cursor
[ http://issues.apache.org/jira/browse/IBATIS-254?page=all ] Sven Boden closed IBATIS-254: - Resolution: Invalid Assign To: Sven Boden support question, refer to the mailing list iBATIS for Java mailing list at http://ibatis.apache.org/mailinglists.html Closing of resultset Cursor --- Key: IBATIS-254 URL: http://issues.apache.org/jira/browse/IBATIS-254 Project: iBatis for Java Type: Bug Reporter: Shiuli Deb Assignee: Sven Boden With reference to my Previous isuue regarding the closing of resultset cursor,I am using Parameter map and result map using queryForList Method.I do not know how and where the resultset cursor gets closed.Please Suggest some possiblities. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (IBATIS-252) closing resultset cursor in Ibatis
[ http://issues.apache.org/jira/browse/IBATIS-252?page=comments#action_12365931 ] Sven Boden commented on IBATIS-252: --- This is a not an iBATIS bug, it's an application design problem (and not in iBATIS). Normally the component in your application that is using the returned ResultSet also has to close it afterwards. If the ResultSet is not used by your application, why do you request it? A short term solution could be to extend your QueueBean, use the new class as class attribute in the parameterMap and close the ResultSet in the setter for resultCursor. I will try close to this JIRA as invalid. Regards, Sven closing resultset cursor in Ibatis -- Key: IBATIS-252 URL: http://issues.apache.org/jira/browse/IBATIS-252 Project: iBatis for Java Type: Bug Components: SQL Maps Environment: ,Ibatis, Java,SQL Server and Oracle 9i Reporter: Shiuli Deb Assignee: Sven Boden Issue is Stored Procedures returns an Cursor. Our application which uses Ibatis Java, SQL Server and Oracle 9i, access those Cursors as Resultset. Also our application doesn't use any extra code for getting resultset. So there is something missing somewhere to close the resultset. Please find a way to close the resultsets after getting the values. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (IBATIS-252) closing resultset cursor in Ibatis
[ http://issues.apache.org/jira/browse/IBATIS-252?page=comments#action_12365852 ] Sven Boden commented on IBATIS-252: --- If you return ResultSets to your application it's the application's responsibility to close them. iBATIS has no way of tracking the state of those ResultSets, it would be the same as when done in JDBC. Just close() the ResultSet after you've extracted all rows. Sven closing resultset cursor in Ibatis -- Key: IBATIS-252 URL: http://issues.apache.org/jira/browse/IBATIS-252 Project: iBatis for Java Type: Bug Components: SQL Maps Environment: ,Ibatis, Java,SQL Server and Oracle 9i Reporter: Shiuli Deb Issue is Stored Procedures returns an Cursor. Our application which uses Ibatis Java, SQL Server and Oracle 9i, access those Cursors as Resultset. Also our application doesn't use any extra code for getting resultset. So there is something missing somewhere to close the resultset. Please find a way to close the resultsets after getting the values. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (IBATIS-250) CLONE -SELECT statement returns unexpected result when 'groupBy' and 'nullValue' are specified in resultMaps.
[ http://issues.apache.org/jira/browse/IBATIS-250?page=all ]
Sven Boden updated IBATIS-250:
--
Attachment: (was: BasicResultMap.java)
CLONE -SELECT statement returns unexpected result when 'groupBy' and
'nullValue' are specified in resultMaps.
-
Key: IBATIS-250
URL: http://issues.apache.org/jira/browse/IBATIS-250
Project: iBatis for Java
Type: Bug
Components: SQL Maps
Versions: 2.1.5
Environment: PowerMac G5 1.8GHz dual, 2.25GB RAM, Mac OS X 10.4.2
Using SqlMaps from tomcat via spring framework.
Reporter: Iwao AVE!
Assignee: Clinton Begin
Fix For: 2.1.7
Attachments: BasicResultMap.zip
[Preparation]
-- Database
CREATE TABLE parent ( parentId, parentName );
CREATE TABLE child ( childId, parentId, childName, childAge );
INSERT INTO parent ( parentId, parentName ) VALUES ( 1, 'Mr Parent' );
-- Java classes.
public class Parent
{
private int parentId;
private String parentName;
private List childList;
// accessor methods...
}
public class Child
{
private int childId;
private String childName;
private int childAge;
// accessor methods...
}
--SqlMap.
sqlMap namespace=Family
resultMap id=parentResult class=Parent groupBy=parentId
result property=parentId column=parentId/
result property=parentName column=parentName/
result property=childList resultMap=Family.childResult/
/resultMap
resultMap id=childResult class=Child
result property=childId column=childId/
result property=childName column=childName/
result property=childAge column=childAge nullValue=0/
/resultMap
select id=getParent resultMap=parentResult parameterClass=int
SELECT
parent.parentId, parent.parentName,
child.childId, child.childName, child.childAge
FROM parent
LEFT JOIN child ON parent.parentId = child.parentId
WHERE
parent.parentId = #value#
/select
/sqlMap
--
[Test]
Executing statement getParent with parameter '1'.
[Expected result]
Query returns 1 'Parent' object and 'childList' property of it is empty
(doesn't mean null).
[Actual result]
The 'childList' property of the returned 'Parent' contains 1 'Child' object.
[Additional information]
If 'nullValue' is not specified in 'childResult', it works as expected.
But this, of course, causes an error if there is a row in the 'child' table
and the 'childAge' column is null.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (IBATIS-250) CLONE -SELECT statement returns unexpected result when 'groupBy' and 'nullValue' are specified in resultMaps.
[
http://issues.apache.org/jira/browse/IBATIS-250?page=comments#action_12364081 ]
Sven Boden commented on IBATIS-250:
---
Iwao,
The original version of the change worked, but there was a problem transcribing
it to SVN. My fault, I didn't check. I will attach a patch to the current file
in SVN to this JIRA issue, basically lines 561, 567, 568, 569 should be deleted
and then it works as it should.
doNullMapping and getPrimitiveResultMappingValue have some duplicated
functionality. Originally they were 1 method, the split was required so that
the null mapping was separated out. Since you first have to check whether you
have all nulls in the child result (to determine to make a child object or
not), and only then apply the null mapping (else you never get all nulls).
Your change does the duplication a third time, so I would actually like to have
the patch above.
Iwoa, as short term fix can you try to use the patch I will upload to this
issue.
Clinton, can this still be put in version 2.1.7.
Regards,
Sven
CLONE -SELECT statement returns unexpected result when 'groupBy' and
'nullValue' are specified in resultMaps.
-
Key: IBATIS-250
URL: http://issues.apache.org/jira/browse/IBATIS-250
Project: iBatis for Java
Type: Bug
Components: SQL Maps
Versions: 2.1.5
Environment: PowerMac G5 1.8GHz dual, 2.25GB RAM, Mac OS X 10.4.2
Using SqlMaps from tomcat via spring framework.
Reporter: Iwao AVE!
Assignee: Clinton Begin
Fix For: 2.1.7
Attachments: BasicResultMap.zip
[Preparation]
-- Database
CREATE TABLE parent ( parentId, parentName );
CREATE TABLE child ( childId, parentId, childName, childAge );
INSERT INTO parent ( parentId, parentName ) VALUES ( 1, 'Mr Parent' );
-- Java classes.
public class Parent
{
private int parentId;
private String parentName;
private List childList;
// accessor methods...
}
public class Child
{
private int childId;
private String childName;
private int childAge;
// accessor methods...
}
--SqlMap.
sqlMap namespace=Family
resultMap id=parentResult class=Parent groupBy=parentId
result property=parentId column=parentId/
result property=parentName column=parentName/
result property=childList resultMap=Family.childResult/
/resultMap
resultMap id=childResult class=Child
result property=childId column=childId/
result property=childName column=childName/
result property=childAge column=childAge nullValue=0/
/resultMap
select id=getParent resultMap=parentResult parameterClass=int
SELECT
parent.parentId, parent.parentName,
child.childId, child.childName, child.childAge
FROM parent
LEFT JOIN child ON parent.parentId = child.parentId
WHERE
parent.parentId = #value#
/select
/sqlMap
--
[Test]
Executing statement getParent with parameter '1'.
[Expected result]
Query returns 1 'Parent' object and 'childList' property of it is empty
(doesn't mean null).
[Actual result]
The 'childList' property of the returned 'Parent' contains 1 'Child' object.
[Additional information]
If 'nullValue' is not specified in 'childResult', it works as expected.
But this, of course, causes an error if there is a row in the 'child' table
and the 'childAge' column is null.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (IBATIS-250) CLONE -SELECT statement returns unexpected result when 'groupBy' and 'nullValue' are specified in resultMaps.
[ http://issues.apache.org/jira/browse/IBATIS-250?page=all ]
Sven Boden updated IBATIS-250:
--
Attachment: BasicResultMap.java
The patch to the current SVN file of version 2.1.7 ... for the solution only
lines should be deleted from the source code.
CLONE -SELECT statement returns unexpected result when 'groupBy' and
'nullValue' are specified in resultMaps.
-
Key: IBATIS-250
URL: http://issues.apache.org/jira/browse/IBATIS-250
Project: iBatis for Java
Type: Bug
Components: SQL Maps
Versions: 2.1.5
Environment: PowerMac G5 1.8GHz dual, 2.25GB RAM, Mac OS X 10.4.2
Using SqlMaps from tomcat via spring framework.
Reporter: Iwao AVE!
Assignee: Clinton Begin
Fix For: 2.1.7
Attachments: BasicResultMap.java, BasicResultMap.zip
[Preparation]
-- Database
CREATE TABLE parent ( parentId, parentName );
CREATE TABLE child ( childId, parentId, childName, childAge );
INSERT INTO parent ( parentId, parentName ) VALUES ( 1, 'Mr Parent' );
-- Java classes.
public class Parent
{
private int parentId;
private String parentName;
private List childList;
// accessor methods...
}
public class Child
{
private int childId;
private String childName;
private int childAge;
// accessor methods...
}
--SqlMap.
sqlMap namespace=Family
resultMap id=parentResult class=Parent groupBy=parentId
result property=parentId column=parentId/
result property=parentName column=parentName/
result property=childList resultMap=Family.childResult/
/resultMap
resultMap id=childResult class=Child
result property=childId column=childId/
result property=childName column=childName/
result property=childAge column=childAge nullValue=0/
/resultMap
select id=getParent resultMap=parentResult parameterClass=int
SELECT
parent.parentId, parent.parentName,
child.childId, child.childName, child.childAge
FROM parent
LEFT JOIN child ON parent.parentId = child.parentId
WHERE
parent.parentId = #value#
/select
/sqlMap
--
[Test]
Executing statement getParent with parameter '1'.
[Expected result]
Query returns 1 'Parent' object and 'childList' property of it is empty
(doesn't mean null).
[Actual result]
The 'childList' property of the returned 'Parent' contains 1 'Child' object.
[Additional information]
If 'nullValue' is not specified in 'childResult', it works as expected.
But this, of course, causes an error if there is a row in the 'child' table
and the 'childAge' column is null.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (IBATIS-203) Sql comments inside sqlMap's select tag, throws exception
[
http://issues.apache.org/jira/browse/IBATIS-203?page=comments#action_12360956 ]
Sven Boden commented on IBATIS-203:
---
The problem is in class com.ibatis.sqlmap.engine.mapping.sql.SQLText in the
method:
public void setText(String text) {
this.text = text.replace('\r', ' ').replace('\n', ' ');
this.isWhiteSpace = text.trim().length() == 0;
}
Removing the first line of the method would solve the problem.
However this is the same old problem again of using the SQL query how it is
specified in the XML file or pretty printing it. Removing the first line
would make the logging output a little less nice.
Another solution would be to use the query as is (including newlines), and only
pretty printing the SQL statement when it's actually required for logging
purposes (this would also be a little faster without logging on).
Regards,
Sven
Sql comments inside sqlMap's select tag, throws exception
-
Key: IBATIS-203
URL: http://issues.apache.org/jira/browse/IBATIS-203
Project: iBatis for Java
Type: Improvement
Components: SQL Maps
Versions: 2.1.5
Environment: WinXP
Reporter: Henrik Westman
Using sql comments i.e. lines prepended with --, causes an exception.
Seems like ibatis, parses the CDATA content of the select tag,
into one long line without any newlines.
ex.
select
![CDATA[
select * from myTable
-- here is my comment
where myCol = 5
]]
/select
gets parsed into
select * from myTable -- here is my comment where myCol = 5
which is now invalid sql.
Not being able to comment is annoying
when you have very long SQL statements.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (IBATIS-224) isNotNull node causes typehandler mappings in statement to fail
[ http://issues.apache.org/jira/browse/IBATIS-224?page=comments#action_12360822 ] Sven Boden commented on IBATIS-224: --- I spent 2 hours to create a test case to mimic the problem above, I failed. iBATIS keeps on working as it should. Possibly something is wrong with the mapping of the custom type handlers in use in the original problem. So if the original reporter could post more of his application, or construct a small (complete) test case that shows the failure then we can debug and fix it. Regards, Sven isNotNull node causes typehandler mappings in statement to fail --- Key: IBATIS-224 URL: http://issues.apache.org/jira/browse/IBATIS-224 Project: iBatis for Java Type: Bug Components: SQL Maps Versions: 2.1.6 Environment: linux/java 1.5 Reporter: Reuben Firmin Priority: Critical Here's my insert statement. insert id=createDeployment parameterClass=deployment INSERT INTO Deployment ( environmentId, deploymentTypeId, deploymentStatusId, deploymentTime isNotNull property=threadCountOverride,threadCountOverride/isNotNull ) VALUES ( #environmentId#, #deploymentTypeId#, #deploymentStatusId#, #deploymentTime# isNotNull property=threadCountOverride,#threadCountOverride#/isNotNull ) selectKey resultClass=int keyProperty=deploymentId SELECT @@IDENTITY as value /selectKey /insert deploymentTypeId and deploymentStatusId are enums in the bean, mapped to values using custom type handlers. Without the isNotNull structure around threadCountOverride (which *is* nullable), the statement works. With the isNotNull, deploymentStatusId and deploymentTypeId are mapped to UnknownTypeHandler, and the insert fails to map the parameters from the bean. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (IBATIS-231) Grougby for 1:1 relationship
[
http://issues.apache.org/jira/browse/IBATIS-231?page=comments#action_12359924 ]
Sven Boden commented on IBATIS-231:
---
I'm pretty sure this is a non-issue... Why would you use group by for a
guaranteed 1:1 relationship. You can look at the attachment in JIRA-227 to see
an example of 1:1 containment relationship without using group by.
The reason for the List in group by is that it's not sure your relationship
is 1:1. If more than 1 row would satisfy the group by for 1 parent object you
need a List to store the children.
Unless countered this JIRA can be closed as invalid.
Regards,
Sven
Grougby for 1:1 relationship
Key: IBATIS-231
URL: http://issues.apache.org/jira/browse/IBATIS-231
Project: iBatis for Java
Type: Wish
Components: SQL Maps
Environment: Windows
Reporter: Leo Tu
I have two classes, one is Parent(master) another is Child(Detail), but they
are 1:1 relationship,
The question is that in child class contains just one parent object, but i
must use List for getter/setter elsewise
has problem, why ?
===
// parent
public class CustGroup {
...
}
// child
public class Cust {
...
private CustGroup custGroup; // 1:1
...
public void setCustGroupjava.util.List custGroupList) { ... } // why it
must be List data type ?
public java.util.List getCustGroup() { ... } // why it must be List data
type ?
...
}
resultMap id=CustGroup-result class=CustGroup
...
/resultMap
resultMap id=CUST-result class=Cust
...
result property=custGroup resultMap=CUST_GROUP/ !-- 1:1 --
/resultMap
===
1:1, but groupby must use List for getter/setter,
Can't use
public void setCustGroup(CustGroup custGroup) { ... } // I hope can use
this methd
public CustGroup getCustGroup() { ... } // I hope can use this methd
Best Regards,
Leo
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (IBATIS-190) Duplicate alias-check
[ http://issues.apache.org/jira/browse/IBATIS-190?page=comments#action_12359238 ] Sven Boden commented on IBATIS-190: --- IBATIS-190 can be closed. I tried to debug the problem, but the fix is already in SVN. In com.ibatis.sqlmap.engine.type.TypeHandlerFactory method putTypeAlias() a check is done for existing type aliases, and an SqlMapException is thrown when a typealias appears more than once with a different value. Duplicate alias-check - Key: IBATIS-190 URL: http://issues.apache.org/jira/browse/IBATIS-190 Project: iBatis for Java Type: Improvement Components: SQL Maps Reporter: Niels Beekman Priority: Minor Currently iBATIS accepts multiple types from the same alias, it would be nice if iBATIS throws an exception when overriding a previously created alias, this could save some debugging. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (IBATIS-227) CLONE -Dynamic SQL from JavaBean property causes malformed SQL
[ http://issues.apache.org/jira/browse/IBATIS-227?page=all ] Sven Boden updated IBATIS-227: -- Attachment: jira227_testcase.zip Attached a small JUnit test case that demonstrates the JIRA IBATIS-227. It was made using Oracle as database, and a build file is lacking. Short term fix is to put a space after the and in the prepend attribute... I don't belief spaces in an attribute value will be trimmed. Sven Boden CLONE -Dynamic SQL from JavaBean property causes malformed SQL -- Key: IBATIS-227 URL: http://issues.apache.org/jira/browse/IBATIS-227 Project: iBatis for Java Type: Bug Components: SQL Maps Reporter: Luke R. Flesch Assignee: Clinton Begin Fix For: 2.0.8 Attachments: jira227_testcase.zip If there is a 'staff' class (mapped via a typeAlias) with a property 'salutation' which is of type 'Salutation' (itself a JavaBean), then the following dynamic SQL fragment causes an exception to be thrown: select id=searchForStaff parameterClass=staff resultMap=staffResult select * from staff dynamic prepend=where isNotNull prepend=and property=lastNamelast_name = #lastName#/isNotNull isNotNull prepend=and property=salutationsalutation_id = #salutation.id#/isNotNull /dynamic /select Note the access of the 'id' property of the Salutation JavaBean and the absence of whitespace between the 'isNotNull' tag and its text content (the examples in the tutorial and developer guide have whitespace, avoiding the problem). The exception is a SQLException stating that the SQL command is not properly ended. Inspection of the SQL shows that a space is omitted between the 'and' and the condition, i.e. '... andsalutation_id = ...'. This only occurs when it is a JavaBean property being accessed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (IBATIS-220) Null Pointer in SqlExecutor.handleResults where ResultSet is null.
[ http://issues.apache.org/jira/browse/IBATIS-220?page=comments#action_12358073 ] Sven Boden commented on IBATIS-220: --- - Are you using custom type handlers? - can you attach your xml maps to JIRA? Regards, Sven Null Pointer in SqlExecutor.handleResults where ResultSet is null. -- Key: IBATIS-220 URL: http://issues.apache.org/jira/browse/IBATIS-220 Project: iBatis for Java Type: Bug Versions: 2.1.5, 2.1.6 Environment: Windows XP Pro MS SQL Server Reporter: Bret Gregory I recently ran into a problem while executing a stored procedure using an inline map in iBatis 2.1.5_582. I tested this in 2.1.6_592 to see if the problem was resolved and I am still running into the issue. I am not sure if this is specific to the JDBC implementation for my SQL Server driver or not. Caused by: java.lang.NullPointerException at com.ibatis.sqlmap.engine.execution.SqlExecutor.handleResults(SqlExecutor.java:355) at com.ibatis.sqlmap.engine.execution.SqlExecutor.executeQueryProcedure(SqlExecutor.java:291) at com.ibatis.sqlmap.engine.mapping.statement.ProcedureStatement.sqlExecuteQuery(ProcedureStatement.java:34) at com.ibatis.sqlmap.engine.mapping.statement.GeneralStatement.executeQueryWithCallback(GeneralStatement.java:173) The problem looks to be caused by the callable statement not returning a result set in the executeQueryProcedure method. The rs variable is set to null and passed into the handleResults() method. This method attempts to get the Type, and the Null Pointer is thrown. This looks like a bug and this code executes normally in iBatis 2.0.9. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (IBATIS-193) Hidden jar dependicity for iBatis DBL 2.1.5
[ http://issues.apache.org/jira/browse/IBATIS-193?page=comments#action_12330498 ] Sven Boden commented on IBATIS-193: --- Commons logging has a discovery process for determining which kind of logging to use. My hunch would be that you somehow you explicitly order Commons logging to use Log4J. Which explains your cases: 1) commons-logging.jar and log4j.jar in classpath... iBATIS uses commons logging and that internally uses log4j (forced by you, but would be the first default anyway) 2) log4j in classpath... iBATIS uses log4j, commons logging not involved 3) commons-logging.jar but no log4j.jar in classpath... iBATIS uses commons-logging.jar and if you're using only defaults commons logging will first try log4j, JDK1.4, JDK1.3 and SimpleLog... but in your case it fails when log4j.jar is not present. For 3) I assume you force commons logging to use log4j which isn't in the classpath, a lot of times this is forced via the commons logging properties file: commons-logging.properties Can you look for that file and report back the contents... Hint: if it mentions log4j you have found the culprit. If you want to debug yourself a bit, look at the class: com.ibatis.common.logging.LogFactory. This is where the logging in iBATIS is set up. Regards, Sven Hidden jar dependicity for iBatis DBL 2.1.5 --- Key: IBATIS-193 URL: http://issues.apache.org/jira/browse/IBATIS-193 Project: iBatis for Java Type: Bug Components: SQL Maps Versions: 2.1.5 Environment: JDK 1.4.2 Tomcat 4.1.x Reporter: Dimiter Kapitanov Priority: Minor This issue occurs only if you have commons-logging.jar in your classpath (but NO log4j.jar !) : java.lang.NoClassDefFoundError at com.ibatis.sqlmap.engine.builder.xml.SqlMapConfigParser.init(SqlMapConfigParser.java:53) at com.ibatis.sqlmap.engine.builder.xml.SqlMapConfigParser.init(SqlMapConfigParser.java:40) at com.ibatis.sqlmap.client.SqlMapClientBuilder.buildSqlMapClient(SqlMapClientBuilder.java:78) at astarot.persist.Helper.initPersistance(Helper.java:94) at dsk.jt.JTLogic.configureApplication(JTLogic.java:137) at dsk.jt.JTLogic.init(JTLogic.java:43) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:274) at java.lang.Class.newInstance0(Class.java:308) at java.lang.Class.newInstance(Class.java:261) at astarot.dominator.web.ActionServlet.init(ActionServlet.java:169) at javax.servlet.GenericServlet.init(GenericServlet.java:256) at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:935) at org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:668) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:210) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2422) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:171) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:163) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at
[jira] Commented: (IBATIS-194) No resultSet found when executing SQL Server stored procedure.
[
http://issues.apache.org/jira/browse/IBATIS-194?page=comments#action_12330300 ]
Sven Boden commented on IBATIS-194:
---
With the custom Type Handlers you can get a ResultSet back from a stored
procedure via iBATIS. However automatically mapping that to a ResultMap is not
yet in the code, as e.g. requested in IBATIS-154
So this problem is not a problem of not finding a ResultSet, but a problem of
not yet supported functionality.
No resultSet found when executing SQL Server stored procedure.
--
Key: IBATIS-194
URL: http://issues.apache.org/jira/browse/IBATIS-194
Project: iBatis for Java
Type: Bug
Components: SQL Maps
Versions: 2.1.0
Environment: SQL Server 2000
Reporter: Tony Ugando
When executing a SQL Server stored procedure that returns a resultSet, using
the procedure tag, iBATIS does not find a resultSet. I have tested the
procedure with the following lowlevel JDBC code, and it works fine...
Connection con = c_SQL_MAP_CLIENT.getCurrentConnection();
CallableStatement cs = con.prepareCall({call sp_epolice_open_events()});
ResultSet rs = cs.executeQuery();
...
con.close();
The follwing does not work:
XML...
procedure
id=getAllOpenUdtCadEvents
resultMap=cadEvent.result
{call sp_epolice_open_events()}
/procedure
Java DAO Class...
List list = c_SQL_MAP_CLIENT.queryForList(
cadEvent.getAllOpenUdtCadEvents, null);
The follwoing error is produced...
The error occurred in com/mdpd/epolice/resources/cadEvent-sqlMap.xml.
--- The error occurred while applying a parameter map.
--- Check the cadEvent.getAllOpenUdtCadEvents-InlineParameterMap.
--- Check the results (failed to retrieve results).
--- Cause: java.lang.NullPointerException
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (IBATIS-191) operation(insert and update) Oracle's(OCI) CLOB and BLOB fail, CLOB will close tomcat, BLOB will miss any DATA
[
http://issues.apache.org/jira/browse/IBATIS-191?page=comments#action_12330311 ]
Sven Boden commented on IBATIS-191:
---
Could you try using the JDBC library of Oracle 10g. We've had similar problems
in the past that were solved by using the version 10 drivers with Oracle 9i
(Oracle has this even as solution to some Oracle 9i problems in MetaLink).
You can find them at
http://www.oracle.com/technology/software/tech/java/sqlj_jdbc/index.html
Regards,
Sven
operation(insert and update) Oracle's(OCI) CLOB and BLOB fail, CLOB will
close tomcat, BLOB will miss any DATA
Key: IBATIS-191
URL: http://issues.apache.org/jira/browse/IBATIS-191
Project: iBatis for Java
Type: Bug
Components: SQL Maps
Versions: 2.1.5
Environment: Apache/2.0.47 (Win32) PHP/5.1.0b3 mod_jk/1.2.14
Tomcat/4.1.27
jdk1.5.0_02
Oracle 9i2
Reporter: Lear.Li
operation(insert and update) Oracle's(OCI) CLOB and BLOB fail, CLOB will
close tomcat, BLOB will miss any DATA
i has find and fix code in ibatis as:
com.ibatis.sqlmap.engine.type.ClobTypeHandlerCallback
public void setParameter(ParameterSetter setter, Object parameter) throws
SQLException {
String s = (String) parameter;
if (s != null) {
StringReader reader = new StringReader(s);
setter.setCharacterStream(reader, s.length());
} else {
setter.setString(null);
}
//setter.setString((String) parameter); // ? why put the line at
here, i test and find ,set double times, will close tomcat
}
issue:
if remark up line , will ok
com.ibatis.sqlmap.engine.type.BlobTypeHandlerCallback
public void setParameter(ParameterSetter setter, Object parameter)
throws SQLException {
System.out.println([Fixed BLOB SET]);
if (null != parameter) {
byte[] bytes = (byte[]) parameter;
ByteArrayInputStream bis=new ByteArrayInputStream(bytes);
setter.setBinaryStream(bis,(int)(bytes.length));
//setter.setBytes(bytes); // don't use set byte, use setBinaryStream
will ok
}
}
issue:
use setBinaryStream will ok
wish usefull
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (IBATIS-177) java.sql.SQLException: Result set already closed
[ http://issues.apache.org/jira/browse/IBATIS-177?page=comments#action_12318181 ] Sven Boden commented on IBATIS-177: --- Which kind of proofs it's not in iBATIS, but somewhere else. I found your problem at http://e-docs.bea.com/wls/docs70/faq/JTA.html#741271 You can shoot at BEA/Oracle for this, no change in iBATIS will fix this. they don't want you executing queries from the client side. So I guess this JIRA can be closed? Regards, Sven java.sql.SQLException: Result set already closed Key: IBATIS-177 URL: http://issues.apache.org/jira/browse/IBATIS-177 Project: iBatis for Java Type: Bug Components: SQL Maps Versions: 2.1.0 Environment: windows environment, weblogic 8.1, oracle 9.i Reporter: Gunaselan Varathan Attachments: Main.java, RefTypeHandler.java, Test.java, hi.jsp, sql-map-config.xml, test.sql, test.xml Hi, I am trying use oracle cursor. i implemented based on example given in Ibatis-53. But i am getting forllowing error. an di dont whoe why it is happening. Jul 29, 2005 10:54:00 AM EDT Error HTTP BEA-101017 [ServletContext(id=4 929007,name=default,context-path=/default)] Root cause of ServletException. java.sql.SQLException: Result set already closed at weblogic.jdbc.wrapper.ResultSet.checkResultSet(ResultSet.java:103) at weblogic.jdbc.wrapper.ResultSet.preInvocationHandler(ResultSet.java:6 6) at weblogic.jdbc.wrapper.ResultSet_oracle_jdbc_driver_OracleResultSetImp l.next(Unknown Source) at jsp_servlet.__hi._jspService(__hi.java:161) at weblogic.servlet.jsp.JspBase.service(JspBase.java:33) at weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run (ServletStubImpl.java:1006) at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubIm pl.java:419) at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubIm pl.java:315) at weblogic.servlet.internal.WebAppServletContext$ServletInvocationActio n.run(WebAppServletContext.java:6718) at weblogic.security.acl.internal.AuthenticatedSubject.doAs(Authenticate dSubject.java:321) at weblogic.security.service.SecurityManager.runAs(SecurityManager.java: 121) at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppSe rvletContext.java:3764) at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestIm pl.java:2644) at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:219) at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:178) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (IBATIS-152) NullPointer Exception thrown in GeneralStatement.executeQueryWithCallback when using Log4j
[ http://issues.apache.org/jira/browse/IBATIS-152?page=all ]
Sven Boden updated IBATIS-152:
--
Attachment: PreparedStatementLogProxy_final.java
StatementLogProxy_final.java
Full files instead of diff files. The fix solves IBATIS-152 and IBATIS-149 for
sure and possibly IBATIS-116 (impossible to tell without a stack trace).
The fix synchronizes the behaviour between iBatis with and without logging
switched on.
Regards,
Sven Boden
P.S. My CLA has been faxed to Apache
NullPointer Exception thrown in GeneralStatement.executeQueryWithCallback
when using Log4j
--
Key: IBATIS-152
URL: http://issues.apache.org/jira/browse/IBATIS-152
Project: iBatis for Java
Type: Bug
Components: SQL Maps
Versions: 2.1.1
Environment: Windows XP, Java 1.3
Reporter: David Winterbottom
Attachments: PreparedStatementLogProxy.diff, PreparedStatementLogProxy.diff,
PreparedStatementLogProxy.java, PreparedStatementLogProxy_final.java,
RefCursor.zip, StatementLogProxy.diff, StatementLogProxy_final.java
Hi,
I am trying to follow the supplied test for IBATIS-53 (Oracle ref cursors).
I have found that running the supplied test (number 6) with log4j-1.2.9.jar
on
the classpath causes a NullPointerException.
The stack trace and output is:
DEBUG [main] - Created connection 3235124.
DEBUG [main] - {conn-10} Connection
DEBUG [main] - {pstm-11} PreparedStatement: { ? = call
mis_extract.mgr_case_temp.FindCases }
DEBUG [main] - {pstm-11} Parameters: []
DEBUG [main] - {pstm-11} Types: []
DEBUG [main] - {rset-12} ResultSet
DEBUG [main] - Returned connection 3235124 to pool.
com.ibatis.common.jdbc.exception.NestedSQLException:
--- The error occurred in com/kinnect/mis/datamodel/sql/CaseToExtract.xml.
--- The error occurred while applying a parameter map.
--- Check the output.
--- Check the output parameters (retrieval of output parameters failed).
--- Cause: java.lang.NullPointerException
Caused by: java.lang.NullPointerException
at
com.ibatis.sqlmap.engine.mapping.statement.GeneralStatement.executeQueryWithCallback(GeneralStatement.java:184)
at
com.ibatis.sqlmap.engine.mapping.statement.GeneralStatement.executeQueryForObject(GeneralStatement.java:100)
at
com.ibatis.sqlmap.engine.impl.SqlMapExecutorDelegate.queryForObject(SqlMapExecutorDelegate.java:561)
at
com.ibatis.sqlmap.engine.impl.SqlMapExecutorDelegate.queryForObject(SqlMapExecutorDelegate.java:536)
at
com.ibatis.sqlmap.engine.impl.SqlMapSessionImpl.queryForObject(SqlMapSessionImpl.java:97)
at
com.ibatis.sqlmap.engine.impl.SqlMapClientImpl.queryForObject(SqlMapClientImpl.java:69)
at com.kinnect.mis.MISExtract.readCasesToExtract(MISExtract.java:233)
at com.kinnect.mis.MISExtract.main(MISExtract.java:64)
Caused by:
java.lang.NullPointerException
at java.lang.reflect.Method.invoke(Native Method)
at
com.ibatis.common.jdbc.logging.ResultSetLogProxy.invoke(ResultSetLogProxy.java:47)
at $Proxy2.close(Unknown Source)
at
com.ibatis.sqlmap.engine.execution.SqlExecutor.closeResultSet(SqlExecutor.java:392)
at
com.ibatis.sqlmap.engine.execution.SqlExecutor.executeQueryProcedure(SqlExecutor.java:298)
at
com.ibatis.sqlmap.engine.mapping.statement.ProcedureStatement.sqlExecuteQuery(ProcedureStatement.java:34)
at
com.ibatis.sqlmap.engine.mapping.statement.GeneralStatement.executeQueryWithCallback(GeneralStatement.java:169)
at
com.ibatis.sqlmap.engine.mapping.statement.GeneralStatement.executeQueryForObject(GeneralStatement.java:100)
at
com.ibatis.sqlmap.engine.impl.SqlMapExecutorDelegate.queryForObject(SqlMapExecutorDelegate.java:561)
at
com.ibatis.sqlmap.engine.impl.SqlMapExecutorDelegate.queryForObject(SqlMapExecutorDelegate.java:536)
at
com.ibatis.sqlmap.engine.impl.SqlMapSessionImpl.queryForObject(SqlMapSessionImpl.java:97)
at
com.ibatis.sqlmap.engine.impl.SqlMapClientImpl.queryForObject(SqlMapClientImpl.java:69)
at com.kinnect.mis.MISExtract.readCasesToExtract(MISExtract.java:233)
at com.kinnect.mis.MISExtract.main(MISExtract.java:64)
Is there a known problem with log4j with IBatis ?
Is this a problem for RefCursors only ?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (IBATIS-116) New call to return output parameters even if no result set returned
[ http://issues.apache.org/jira/browse/IBATIS-116?page=comments#action_12314007 ] Sven Boden commented on IBATIS-116: --- David, Can you attach the full stack trace you get from the exception. Regards, Sven Boden New call to return output parameters even if no result set returned --- Key: IBATIS-116 URL: http://issues.apache.org/jira/browse/IBATIS-116 Project: iBatis for Java Type: New Feature Components: SQL Maps Versions: 2.1.2 Environment: DB2 (probably plus other databases) Reporter: David Whipple We have legacy stored procedures which have input parameters and output parameters and optional result sets. The application will not be able to determine if the result set is going to be returned or not before the call. If the call to the stored procedure returns a result set, we get the result set and the output parameters just fine. If the call does not return a result set, an exception is thrown, and we do not get the output parameters which are needed by the application. I believe a type of call that can handle this situation would be a good feature. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (IBATIS-116) New call to return output parameters even if no result set returned
[ http://issues.apache.org/jira/browse/IBATIS-116?page=comments#action_12314012 ] Sven Boden commented on IBATIS-116: --- Possibly this would also be fixed by the fix for IBATIS-152 depending on the actual exception stack trace. This is hypothetical... but assuming log4j is used with iBatis returning an empty ResultSet will cause a NullPointerException. Sven New call to return output parameters even if no result set returned --- Key: IBATIS-116 URL: http://issues.apache.org/jira/browse/IBATIS-116 Project: iBatis for Java Type: New Feature Components: SQL Maps Versions: 2.1.2 Environment: DB2 (probably plus other databases) Reporter: David Whipple We have legacy stored procedures which have input parameters and output parameters and optional result sets. The application will not be able to determine if the result set is going to be returned or not before the call. If the call to the stored procedure returns a result set, we get the result set and the output parameters just fine. If the call does not return a result set, an exception is thrown, and we do not get the output parameters which are needed by the application. I believe a type of call that can handle this situation would be a good feature. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (IBATIS-139) Discriminator being applied to incorrect resultmaps
[ http://issues.apache.org/jira/browse/IBATIS-139?page=all ] Sven Boden updated IBATIS-139: -- Attachment: SqlMapParser.diff 1 line change that fixes this issue in com.ibatis.sqlmap.engine.builder.xml.SqlMapParser. Root cause: a discriminator object was created and assigned when it was used in a ResultMap but would never be reset afterwards, causing it to be applied to any ResultMap parsed thereafter. Solution: In the end processing of a ResultMap assign the found discriminator to the current ResultMap and then reset it to null. This makes sure that the discriminator is only valid for the current ResultMap. Discriminator being applied to incorrect resultmaps --- Key: IBATIS-139 URL: http://issues.apache.org/jira/browse/IBATIS-139 Project: iBatis for Java Type: Bug Components: SQL Maps Versions: 2.1.0 Environment: MS Windows XP Professional, JDK 1.3 Reporter: Geoff Chiang Attachments: SqlMapParser.diff The new discriminator/submap functionality is breaking resultmaps that are processed after the one that the discriminator defined in. Once a discriminator tag is encountered during the initial parsing of the resultmaps, a Discriminator object is created and held in the 'discriminator' attribute of the parser's 'vars' object (vars is an instance of BaseParse.Variables). This Discriminator object is then applied to the enclosing resultmap at SqlMapParser:288. However, the discriminator is never reset to null, resulting in it also being applied to all resultmaps processed after that initial definition. See the mailing list thread at http://www.mail-archive.com/ibatis-user-java@incubator.apache.org/msg02500.html for more details of the problem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (IBATIS-152) NullPointer Exception thrown in GeneralStatement.executeQueryWithCallback when using Log4j
[ http://issues.apache.org/jira/browse/IBATIS-152?page=all ]
Sven Boden updated IBATIS-152:
--
Attachment: PreparedStatementLogProxy.diff
diff file
NullPointer Exception thrown in GeneralStatement.executeQueryWithCallback
when using Log4j
--
Key: IBATIS-152
URL: http://issues.apache.org/jira/browse/IBATIS-152
Project: iBatis for Java
Type: Bug
Components: SQL Maps
Versions: 2.1.1
Environment: Windows XP, Java 1.3
Reporter: David Winterbottom
Attachments: PreparedStatementLogProxy.diff, PreparedStatementLogProxy.java,
RefCursor.zip
Hi,
I am trying to follow the supplied test for IBATIS-53 (Oracle ref cursors).
I have found that running the supplied test (number 6) with log4j-1.2.9.jar
on
the classpath causes a NullPointerException.
The stack trace and output is:
DEBUG [main] - Created connection 3235124.
DEBUG [main] - {conn-10} Connection
DEBUG [main] - {pstm-11} PreparedStatement: { ? = call
mis_extract.mgr_case_temp.FindCases }
DEBUG [main] - {pstm-11} Parameters: []
DEBUG [main] - {pstm-11} Types: []
DEBUG [main] - {rset-12} ResultSet
DEBUG [main] - Returned connection 3235124 to pool.
com.ibatis.common.jdbc.exception.NestedSQLException:
--- The error occurred in com/kinnect/mis/datamodel/sql/CaseToExtract.xml.
--- The error occurred while applying a parameter map.
--- Check the output.
--- Check the output parameters (retrieval of output parameters failed).
--- Cause: java.lang.NullPointerException
Caused by: java.lang.NullPointerException
at
com.ibatis.sqlmap.engine.mapping.statement.GeneralStatement.executeQueryWithCallback(GeneralStatement.java:184)
at
com.ibatis.sqlmap.engine.mapping.statement.GeneralStatement.executeQueryForObject(GeneralStatement.java:100)
at
com.ibatis.sqlmap.engine.impl.SqlMapExecutorDelegate.queryForObject(SqlMapExecutorDelegate.java:561)
at
com.ibatis.sqlmap.engine.impl.SqlMapExecutorDelegate.queryForObject(SqlMapExecutorDelegate.java:536)
at
com.ibatis.sqlmap.engine.impl.SqlMapSessionImpl.queryForObject(SqlMapSessionImpl.java:97)
at
com.ibatis.sqlmap.engine.impl.SqlMapClientImpl.queryForObject(SqlMapClientImpl.java:69)
at com.kinnect.mis.MISExtract.readCasesToExtract(MISExtract.java:233)
at com.kinnect.mis.MISExtract.main(MISExtract.java:64)
Caused by:
java.lang.NullPointerException
at java.lang.reflect.Method.invoke(Native Method)
at
com.ibatis.common.jdbc.logging.ResultSetLogProxy.invoke(ResultSetLogProxy.java:47)
at $Proxy2.close(Unknown Source)
at
com.ibatis.sqlmap.engine.execution.SqlExecutor.closeResultSet(SqlExecutor.java:392)
at
com.ibatis.sqlmap.engine.execution.SqlExecutor.executeQueryProcedure(SqlExecutor.java:298)
at
com.ibatis.sqlmap.engine.mapping.statement.ProcedureStatement.sqlExecuteQuery(ProcedureStatement.java:34)
at
com.ibatis.sqlmap.engine.mapping.statement.GeneralStatement.executeQueryWithCallback(GeneralStatement.java:169)
at
com.ibatis.sqlmap.engine.mapping.statement.GeneralStatement.executeQueryForObject(GeneralStatement.java:100)
at
com.ibatis.sqlmap.engine.impl.SqlMapExecutorDelegate.queryForObject(SqlMapExecutorDelegate.java:561)
at
com.ibatis.sqlmap.engine.impl.SqlMapExecutorDelegate.queryForObject(SqlMapExecutorDelegate.java:536)
at
com.ibatis.sqlmap.engine.impl.SqlMapSessionImpl.queryForObject(SqlMapSessionImpl.java:97)
at
com.ibatis.sqlmap.engine.impl.SqlMapClientImpl.queryForObject(SqlMapClientImpl.java:69)
at com.kinnect.mis.MISExtract.readCasesToExtract(MISExtract.java:233)
at com.kinnect.mis.MISExtract.main(MISExtract.java:64)
Is there a known problem with log4j with IBatis ?
Is this a problem for RefCursors only ?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (IBATIS-152) NullPointer Exception thrown in GeneralStatement.executeQueryWithCallback when using Log4j
[ http://issues.apache.org/jira/browse/IBATIS-152?page=all ]
Sven Boden updated IBATIS-152:
--
Attachment: PreparedStatementLogProxy.java
Full file
NullPointer Exception thrown in GeneralStatement.executeQueryWithCallback
when using Log4j
--
Key: IBATIS-152
URL: http://issues.apache.org/jira/browse/IBATIS-152
Project: iBatis for Java
Type: Bug
Components: SQL Maps
Versions: 2.1.1
Environment: Windows XP, Java 1.3
Reporter: David Winterbottom
Attachments: PreparedStatementLogProxy.diff, PreparedStatementLogProxy.java,
RefCursor.zip
Hi,
I am trying to follow the supplied test for IBATIS-53 (Oracle ref cursors).
I have found that running the supplied test (number 6) with log4j-1.2.9.jar
on
the classpath causes a NullPointerException.
The stack trace and output is:
DEBUG [main] - Created connection 3235124.
DEBUG [main] - {conn-10} Connection
DEBUG [main] - {pstm-11} PreparedStatement: { ? = call
mis_extract.mgr_case_temp.FindCases }
DEBUG [main] - {pstm-11} Parameters: []
DEBUG [main] - {pstm-11} Types: []
DEBUG [main] - {rset-12} ResultSet
DEBUG [main] - Returned connection 3235124 to pool.
com.ibatis.common.jdbc.exception.NestedSQLException:
--- The error occurred in com/kinnect/mis/datamodel/sql/CaseToExtract.xml.
--- The error occurred while applying a parameter map.
--- Check the output.
--- Check the output parameters (retrieval of output parameters failed).
--- Cause: java.lang.NullPointerException
Caused by: java.lang.NullPointerException
at
com.ibatis.sqlmap.engine.mapping.statement.GeneralStatement.executeQueryWithCallback(GeneralStatement.java:184)
at
com.ibatis.sqlmap.engine.mapping.statement.GeneralStatement.executeQueryForObject(GeneralStatement.java:100)
at
com.ibatis.sqlmap.engine.impl.SqlMapExecutorDelegate.queryForObject(SqlMapExecutorDelegate.java:561)
at
com.ibatis.sqlmap.engine.impl.SqlMapExecutorDelegate.queryForObject(SqlMapExecutorDelegate.java:536)
at
com.ibatis.sqlmap.engine.impl.SqlMapSessionImpl.queryForObject(SqlMapSessionImpl.java:97)
at
com.ibatis.sqlmap.engine.impl.SqlMapClientImpl.queryForObject(SqlMapClientImpl.java:69)
at com.kinnect.mis.MISExtract.readCasesToExtract(MISExtract.java:233)
at com.kinnect.mis.MISExtract.main(MISExtract.java:64)
Caused by:
java.lang.NullPointerException
at java.lang.reflect.Method.invoke(Native Method)
at
com.ibatis.common.jdbc.logging.ResultSetLogProxy.invoke(ResultSetLogProxy.java:47)
at $Proxy2.close(Unknown Source)
at
com.ibatis.sqlmap.engine.execution.SqlExecutor.closeResultSet(SqlExecutor.java:392)
at
com.ibatis.sqlmap.engine.execution.SqlExecutor.executeQueryProcedure(SqlExecutor.java:298)
at
com.ibatis.sqlmap.engine.mapping.statement.ProcedureStatement.sqlExecuteQuery(ProcedureStatement.java:34)
at
com.ibatis.sqlmap.engine.mapping.statement.GeneralStatement.executeQueryWithCallback(GeneralStatement.java:169)
at
com.ibatis.sqlmap.engine.mapping.statement.GeneralStatement.executeQueryForObject(GeneralStatement.java:100)
at
com.ibatis.sqlmap.engine.impl.SqlMapExecutorDelegate.queryForObject(SqlMapExecutorDelegate.java:561)
at
com.ibatis.sqlmap.engine.impl.SqlMapExecutorDelegate.queryForObject(SqlMapExecutorDelegate.java:536)
at
com.ibatis.sqlmap.engine.impl.SqlMapSessionImpl.queryForObject(SqlMapSessionImpl.java:97)
at
com.ibatis.sqlmap.engine.impl.SqlMapClientImpl.queryForObject(SqlMapClientImpl.java:69)
at com.kinnect.mis.MISExtract.readCasesToExtract(MISExtract.java:233)
at com.kinnect.mis.MISExtract.main(MISExtract.java:64)
Is there a known problem with log4j with IBatis ?
Is this a problem for RefCursors only ?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
