Re: Tests Failed
The unit tests still work... that got me scared for a few minutes. They also still work for Nathan ;-) Sven - Oorspronkelijk bericht - Van: Sven.Boden [mailto:[EMAIL PROTECTED] Verzonden: maandag, februari 20, 2006 08:04 AM Aan: dev@ibatis.apache.org Onderwerp: Re: Tests Failed Specifically which tests failed? I did change the DOCTYPE in the tests to ibatis.apache.org but on my side all testcases still work, it could be you have a more restrictive XML parser installed. Regards, Sven - Oorspronkelijk bericht - Van: Nathan Maves [mailto:[EMAIL PROTECTED] Verzonden: maandag, februari 20, 2006 07:34 AM Aan: dev@ibatis.apache.org Onderwerp: Tests Failed I was working on a few things last night and got stuck with the tests... A bunch of tests all failed with this error not easy to debug :) Error occurred. Cause: com.ibatis.common.xml.NodeletException: Error parsing XML. Cause: com.ibatis.common.exception.NestedRuntimeException: Error parsing XPath '/sqlMapConfig/sqlMap'. Cause: com.ibatis.common.xml.NodeletException: Error parsing XML. Cause: org.xml.sax.SAXParseException: Element resultMap does not allow resultMap here. Caused by: org.xml.sax.SAXParseException: Element resultMap does not allow resultMap here. Caused by: com.ibatis.common.xml.NodeletException: Error parsing XML. Cause: org.xml.sax.SAXParseException: Element resultMap does not allow resultMap here. Caused by: org.xml.sax.SAXParseException: Element resultMap does not allow resultMap here. Caused by: com.ibatis.common.exception.NestedRuntimeException: Error parsing XPath '/sqlMapConfig/sqlMap'. Cause: com.ibatis.common.xml.NodeletException: Error parsing XML. Cause: org.xml.sax.SAXParseException: Element resultMap does not allow resultMap here. Caused by: org.xml.sax.SAXParseException: Element resultMap does not allow resultMap here. Caused by: com.ibatis.common.xml.NodeletException: Error parsing XML. Cause: org.xml.sax.SAXParseException: Element resultMap does not allow resultMap here. Caused by: org.xml.sax.SAXParseException: Element resultMap does not allow resultMap here. com.ibatis.common.exception.NestedRuntimeException: Error occurred. Cause: com.ibatis.common.xml.NodeletException: Error parsing XML. Cause: com.ibatis.common.exception.NestedRuntimeException: Error parsing XPath '/sqlMapConfig/sqlMap'. Cause: com.ibatis.common.xml.NodeletException: Error parsing XML. Cause: org.xml.sax.SAXParseException: Element resultMap does not allow resultMap here. Caused by: org.xml.sax.SAXParseException: Element resultMap does not allow resultMap here. Caused by: com.ibatis.common.xml.NodeletException: Error parsing XML. Cause: org.xml.sax.SAXParseException: Element resultMap does not allow resultMap here. Caused by: org.xml.sax.SAXParseException: Element resultMap does not allow resultMap here. Caused by: com.ibatis.common.exception.NestedRuntimeException: Error parsing XPath '/sqlMapConfig/sqlMap'. Cause: com.ibatis.common.xml.NodeletException: Error parsing XML. Cause: org.xml.sax.SAXParseException: Element resultMap does not allow resultMap here. Caused by: org.xml.sax.SAXParseException: Element resultMap does not allow resultMap here. Caused by: com.ibatis.common.xml.NodeletException: Error parsing XML. Cause: org.xml.sax.SAXParseException: Element resultMap does not allow resultMap here. Caused by: org.xml.sax.SAXParseException: Element resultMap does not allow resultMap here. Caused by: com.ibatis.common.xml.NodeletException: Error parsing XML. Cause: com.ibatis.common.exception.NestedRuntimeException: Error parsing XPath '/sqlMapConfig/sqlMap'. Cause: com.ibatis.common.xml.NodeletException: Error parsing XML. Cause: org.xml.sax.SAXParseException: Element resultMap does not allow resultMap here. Caused by: org.xml.sax.SAXParseException: Element resultMap does not allow resultMap here. Caused by: com.ibatis.common.xml.NodeletException: Error parsing XML. Cause: org.xml.sax.SAXParseException: Element resultMap does not allow resultMap here. Caused by: org.xml.sax.SAXParseException: Element resultMap does not allow resultMap here. Caused by: com.ibatis.common.exception.NestedRuntimeException: Error parsing XPath '/sqlMapConfig/sqlMap'. Cause: com.ibatis.common.xml.NodeletException: Error parsing XML. Cause: org.xml.sax.SAXParseException: Element resultMap does not allow resultMap here. Caused by: org.xml.sax.SAXParseException: Element resultMap does not allow resultMap here. Caused by: com.ibatis.common.xml.NodeletException: Error parsing XML. Cause: org.xml.sax.SAXParseException: Element resultMap does not allow resultMap here. Caused by: org.xml.sax.SAXParseException: Element resultMap does not allow resultMap here. at com.ibatis.sqlmap.engine.builder.xml.SqlMapConfigParser.parse (SqlMapConfigParser.java:82) at com.ibatis.sqlmap.engine.builder.xml.SqlMapConfigParser.parse
[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] Commented: (IBATIS-261) CLONE -The method executor.executeBatch() always returns 0.
[
http://issues.apache.org/jira/browse/IBATIS-261?page=comments#action_12367022 ]
Arne Burmeister commented on IBATIS-261:
Neither Oracle 9 or 10 Driver worked - the current setup is client/server
Oracle 10:
Database: jdbc:oracle:thin:@server1521:db (Oracle Oracle Database 10g
Release 10.1.0.3.0 - Production)
Driver: Oracle JDBC driver 10.2.0.1.0
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
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
Re: removeFirstPrepend doesn't remove the first prepend?
Drop a bug in JIRA and attach a simple example that reproduces this
behavior and i'll take a look at it.
Brandon
On 2/20/06, Petr Kokorev [EMAIL PROTECTED] wrote:
Brandon Goodin wrote:
The removeFirstPrepend does not work in the way you are expecting. The
rFP works to remove the first prepend that is produced by tags nested
in the body of the tag using the rFP. Als, the dyanmic tag should
automatically remove the first prepend. So, in your case you should
remove the rFP from the isNotEmpty tags. It should then work in the
manner you expect. If it does not, then we may have an issue.
Brandon
On 2/17/06, Petr Kokorev [EMAIL PROTECTED] wrote:
Hello,
I have a simple insert query like this (I am sure that at least one of
the properties is not empty)
insert id=insertItem parameterClass=item
INSERT INTO ITEMS_TABLE
(
dynamic
isNotEmpty prepend=, property=propertyOne
removeFirstPrepend=true
PROPERTY_ONE
/isNotEmpty
isNotEmpty prepend=, property=propertyTwo
removeFirstPrepend=true
PROPERTY_TWO
/isNotEmpty
/dynamic
,
VALUE
)
VALUES
(
dynamic
isNotEmpty prepend=, property=propertyOne
removeFirstPrepend=true
#propertyOne#
/isNotEmpty
isNotEmpty prepend=, property=propertyTwo
removeFirstPrepend=true
#propertyTwo#
/isNotEmpty
/dynamic
,
#value:NUMERIC#
)
/insert
The generated String for the prepared statement will be like this in the
case of when both of the properties are not empty:
INSERT INTO ITEMS_TABLE ( , PROPERTY_ONE , PROPERTY_TWO , VALUE )
VALUES ( , ? , ? , ? )
So the 1st prepend is not being removed.
I have done a workaround for it by specifying the prepend attribute for
the dynamic element:
dynamic prepend=(
Then it worked fine:
INSERT INTO ITEMS_TABLE ( PROPERTY_ONE , PROPERTY_TWO , VALUE ) VALUES
( ? , ? , ? )
I just wonder, is it normal?
Because I find the 'prepend=(' thing a bit ugly, and I would like to
have it like in my example.
Thanks in advance and respect
Pye
Hello again
I tried what you have recomended, I removed all the rFP attributes from
isNotEmpty tags - the result was absolutely the same as the last time.
If you do not specify the 'prepend=...' attribute in dynamic tag,
the first prepend is not removed.
Cheers
Pye
[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] Created: (IBATIS-262) jpetstore-iBatis and db2 compatibility
jpetstore-iBatis and db2 compatibility -- Key: IBATIS-262 URL: http://issues.apache.org/jira/browse/IBATIS-262 Project: iBatis for Java Type: Improvement Components: SQL Maps Versions: 2.1.7 Environment: DB2 Environment Reporter: Harinder Nandyala Priority: Minor SQL Map which needs a fix: select id=getItem resultClass=item parameterClass=string cacheModel=quantityCache select ITEMID, LISTPRICE, UNITCOST, SUPPLIER AS supplierId, I.PRODUCTID AS product.productId, NAME AS product.name, DESCN AS product.description, CATEGORY AS product.categoryId, STATUS, ATTR1 AS attribute1, ATTR2 AS attribute2, ATTR3 AS attribute3, ATTR4 AS attribute4, ATTR5 AS attribute5, QTY AS quantity from ITEM I, INVENTORY V, PRODUCT P where P.PRODUCTID = I.PRODUCTID and I.ITEMID = V.ITEMID and I.ITEMID = #value# /select Error reported when tested from WSAD, iBatis and DB2: Caused by: com.ibatis.dao.client.DaoException: Failed to execute queryForObject - id [getItem], parameterObject [EST-6]. Cause: com.ibatis.common.jdbc.exception.NestedSQLException: --- The error occurred in com/ibatis/jpetstore/persistence/sqlmapdao/sql/Item.xml. --- The error occurred while applying a parameter map. --- Check the getItem-InlineParameterMap. --- Check the statement (query failed). --- Cause: COM.ibm.db2.jdbc.DB2Exception: [IBM][CLI Driver][DB2/NT] SQL0203N A reference to column ITEMID is ambiguous. SQLSTATE=42702 Quote from Jeff's mail*** This error means that a column in the select list is in two or more of the joined tables. You must qualify the column name with the table (or alias) in the select list. It looks to me like the getItem query is probably the offending one. Simple solution - put i. in front of the itemid like this: SELECT I.ITEMID ... There may be more of these, you'll have to work them through. I would consider this a bug in JPetStore (hsqldb must be very forgiving - my guess is that this would fail on most databases). It would be good of you to open a JIRA ticket with the details so we don't forget to make a change. Jeff Butler -- 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] Created: (IBATIS-263) Ignore case on type aliases
Ignore case on type aliases --- Key: IBATIS-263 URL: http://issues.apache.org/jira/browse/IBATIS-263 Project: iBatis for Java Type: Improvement Components: SQL Maps Versions: 2.1.7 Reporter: Nathan Maves Assigned to: Nathan Maves Priority: Trivial All of the following, String, string, and StRiNg, should resolve to java.lang.String. -- 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
