[jira] [Commented] (DBUTILS-105) Add Named Parameter Support
[ https://issues.apache.org/jira/browse/DBUTILS-105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14548553#comment-14548553 ] William R. Speirs commented on DBUTILS-105: --- Someone to shepherd it through the release process and the group to accept a 2.0 release. I've made these changes (and more) here: https://github.com/wspeirs/sop4j-dbutils You can access this package via Maven: http://mvnrepository.com/artifact/com.sop4j/dbutils/2.2 Add Named Parameter Support --- Key: DBUTILS-105 URL: https://issues.apache.org/jira/browse/DBUTILS-105 Project: Commons DbUtils Issue Type: Improvement Affects Versions: 2.0 Reporter: William R. Speirs Assignee: William R. Speirs Priority: Minor It's 2013 (don't read before 2013) and we should have the ability to used named params instead of just position params. Because Oracle uses colon for something or another, we should handle both #param and :param. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (DBUTILS-104) Add support for calling stored procs with return values
[ https://issues.apache.org/jira/browse/DBUTILS-104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William R. Speirs resolved DBUTILS-104. --- Resolution: Duplicate This is getting resolved in DBUTILS-50 Add support for calling stored procs with return values --- Key: DBUTILS-104 URL: https://issues.apache.org/jira/browse/DBUTILS-104 Project: Commons DbUtils Issue Type: Improvement Affects Versions: 1.6, 2.0 Reporter: William R. Speirs Assignee: William R. Speirs Calling stored procs can have both return values (usually only an integer) and out parameters. Currently QueryRunner doesn't handle return values making it impossible to call these types of stored procs. Add functionality for handling sotred procs that return values. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DBCP-418) Cannot Disable JMX
[ https://issues.apache.org/jira/browse/DBCP-418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William R. Speirs updated DBCP-418: --- Summary: Cannot Disable JMX (was: Connot Disable JMX) Cannot Disable JMX -- Key: DBCP-418 URL: https://issues.apache.org/jira/browse/DBCP-418 Project: Commons Dbcp Issue Type: Bug Affects Versions: 2.0 Environment: Google App Engine Reporter: William R. Speirs There is no way to disable the use of JMX when using PoolableConnections. Line 48 of PoolableConnection.java uses the ManagementFactory which is blacklisted in Google App Engine. private static MBeanServer MBEAN_SERVER = ManagementFactory.getPlatformMBeanServer(); There should be a way to disable all JMX bindings for environments like GAE. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (DBCP-418) Connot Disable JMX
William R. Speirs created DBCP-418: -- Summary: Connot Disable JMX Key: DBCP-418 URL: https://issues.apache.org/jira/browse/DBCP-418 Project: Commons Dbcp Issue Type: Bug Affects Versions: 2.0 Environment: Google App Engine Reporter: William R. Speirs There is no way to disable the use of JMX when using PoolableConnections. Line 48 of PoolableConnection.java uses the ManagementFactory which is blacklisted in Google App Engine. private static MBeanServer MBEAN_SERVER = ManagementFactory.getPlatformMBeanServer(); There should be a way to disable all JMX bindings for environments like GAE. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (DBUTILS-107) Patch QueryLoader to also load from XML properties files
[ https://issues.apache.org/jira/browse/DBUTILS-107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William R. Speirs resolved DBUTILS-107. --- Resolution: Fixed Fix Version/s: 1.6 Patch applied in r1482047 Patch QueryLoader to also load from XML properties files Key: DBUTILS-107 URL: https://issues.apache.org/jira/browse/DBUTILS-107 Project: Commons DbUtils Issue Type: Improvement Affects Versions: 1.5 Reporter: PB Priority: Minor Fix For: 1.6 Attachments: DBUTILS-107.patch This is a request to patch QueryLoader so that it calls loadFromXML when an XML properties file is provided. Maintenance of long, multi-line queries can be preferable in XML format compared to properties file format. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (DBUTILS-108) Create functionality to return auto-generated keys in batches of SQL inserts
[ https://issues.apache.org/jira/browse/DBUTILS-108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William R. Speirs resolved DBUTILS-108. --- Resolution: Fixed Patch applied in r1482045 Create functionality to return auto-generated keys in batches of SQL inserts Key: DBUTILS-108 URL: https://issues.apache.org/jira/browse/DBUTILS-108 Project: Commons DbUtils Issue Type: Improvement Affects Versions: 1.6 Reporter: Micah Huff Fix For: 1.6 Attachments: dbutils-108.patch Related to DBUTILS-87, there should be support for retrieving the automatically-generated keys from a batch insert operation. Similar to how singular insert was added to return the generated key, there should be an insertBatch operation that allows the ResultSetHandler to perform an operation with the newly generated keys. I have a patch and will be submitting it soon for review. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (DBUTILS-100) columnLabel and columnname
[ https://issues.apache.org/jira/browse/DBUTILS-100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William R. Speirs resolved DBUTILS-100. --- Resolution: Fixed Fix Version/s: 1.6 Fix applied in r1482051. columnLabel and columnname --- Key: DBUTILS-100 URL: https://issues.apache.org/jira/browse/DBUTILS-100 Project: Commons DbUtils Issue Type: Improvement Reporter: xiaofei.xu Fix For: 1.6 The method toMap(ResultSet rs) should use getColumnLabel() -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DBUTILS-109) AbstractExecutor.currentPosition should be an int
[ https://issues.apache.org/jira/browse/DBUTILS-109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13656294#comment-13656294 ] William R. Speirs commented on DBUTILS-109: --- Sebb I think you fixed this in http://svn.apache.org/r1481212 right? AbstractExecutor.currentPosition should be an int - Key: DBUTILS-109 URL: https://issues.apache.org/jira/browse/DBUTILS-109 Project: Commons DbUtils Issue Type: Bug Reporter: Sebb AbstractExecutor.currentPosition is currently an Integer. It is only used here: posList.add(++currentPosition); This involves converting the Integer to an int, incrementing the int and then converting back to an Integer. It would be rather more efficient to create the field as an int. Alternatively, if the class is supposed to be thread-safe, maybe an AtomicInteger would be better. Integer is not the best choice here. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (DBUTILS-95) Remove all of the deprecated code
[ https://issues.apache.org/jira/browse/DBUTILS-95?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William R. Speirs resolved DBUTILS-95. -- Resolution: Fixed Assignee: William R. Speirs Deprecated code removed in r1449890 Remove all of the deprecated code - Key: DBUTILS-95 URL: https://issues.apache.org/jira/browse/DBUTILS-95 Project: Commons DbUtils Issue Type: Improvement Affects Versions: 2.0 Reporter: Stevo Slavic Assignee: William R. Speirs Fix For: 2.0 There's some deprecated code in the project. All of it should be removed for good. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DBUTILS-104) Add support for calling stored procs with return values
[ https://issues.apache.org/jira/browse/DBUTILS-104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William R. Speirs updated DBUTILS-104: -- Affects Version/s: 2.0 Add support for calling stored procs with return values --- Key: DBUTILS-104 URL: https://issues.apache.org/jira/browse/DBUTILS-104 Project: Commons DbUtils Issue Type: Improvement Affects Versions: 2.0, 1.6 Reporter: William R. Speirs Assignee: William R. Speirs Calling stored procs can have both return values (usually only an integer) and out parameters. Currently QueryRunner doesn't handle return values making it impossible to call these types of stored procs. Add functionality for handling sotred procs that return values. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DBUTILS-105) Add Named Parameter Support
[ https://issues.apache.org/jira/browse/DBUTILS-105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William R. Speirs updated DBUTILS-105: -- Affects Version/s: (was: 1.6) 2.0 Add Named Parameter Support --- Key: DBUTILS-105 URL: https://issues.apache.org/jira/browse/DBUTILS-105 Project: Commons DbUtils Issue Type: Improvement Affects Versions: 2.0 Reporter: William R. Speirs Assignee: William R. Speirs Priority: Minor It's 2013 (don't read before 2013) and we should have the ability to used named params instead of just position params. Because Oracle uses colon for something or another, we should handle both #param and :param. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DBUTILS-105) Add Named Parameter Support
[ https://issues.apache.org/jira/browse/DBUTILS-105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587572#comment-13587572 ] William R. Speirs commented on DBUTILS-105: --- Named params were added in r1450009 (and subsequent revisions: r1450376). Please take a look at my implementation and provide feedback: http://svn.apache.org/viewvc/commons/proper/dbutils/branches/2_0/ Thanks in advance... Add Named Parameter Support --- Key: DBUTILS-105 URL: https://issues.apache.org/jira/browse/DBUTILS-105 Project: Commons DbUtils Issue Type: Improvement Affects Versions: 2.0 Reporter: William R. Speirs Assignee: William R. Speirs Priority: Minor It's 2013 (don't read before 2013) and we should have the ability to used named params instead of just position params. Because Oracle uses colon for something or another, we should handle both #param and :param. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (DBUTILS-99) Create QueryRunner Factory
[ https://issues.apache.org/jira/browse/DBUTILS-99?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William R. Speirs closed DBUTILS-99. Create QueryRunner Factory -- Key: DBUTILS-99 URL: https://issues.apache.org/jira/browse/DBUTILS-99 Project: Commons DbUtils Issue Type: Improvement Affects Versions: 1.5 Reporter: William R. Speirs Assignee: William R. Speirs Priority: Minor Fix For: 1.5 Currently there is no good way to use dependency injection with QueryRunners. Creating a simple factory class to allow for easy injection (and therefore easier unit test creation) should solve this problem. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (DBUTILS-104) Add support for calling stored procs with return values
William R. Speirs created DBUTILS-104: - Summary: Add support for calling stored procs with return values Key: DBUTILS-104 URL: https://issues.apache.org/jira/browse/DBUTILS-104 Project: Commons DbUtils Issue Type: Improvement Affects Versions: 1.6 Reporter: William R. Speirs Assignee: William R. Speirs Calling stored procs can have both return values (usually only an integer) and out parameters. Currently QueryRunner doesn't handle return values making it impossible to call these types of stored procs. Add functionality for handling sotred procs that return values. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (DBUTILS-105) Add Named Parameter Support
William R. Speirs created DBUTILS-105: - Summary: Add Named Parameter Support Key: DBUTILS-105 URL: https://issues.apache.org/jira/browse/DBUTILS-105 Project: Commons DbUtils Issue Type: Improvement Affects Versions: 1.6 Reporter: William R. Speirs Assignee: William R. Speirs Priority: Minor It's 2013 (don't read before 2013) and we should have the ability to used named params instead of just position params. Because Oracle uses colon for something or another, we should handle both #param and :param. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DBUTILS-102) com.microsoft.sqlserver.jdbc.SQLServerException: Incorrect syntax near the keyword 'WHERE'
[
https://issues.apache.org/jira/browse/DBUTILS-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13471233#comment-13471233
]
William R. Speirs commented on DBUTILS-102:
---
I think this is simply a meta-data issue. Have you tried using the following
constructor:
http://commons.apache.org/dbutils/apidocs/org/apache/commons/dbutils/QueryRunner.html#QueryRunner(javax.sql.DataSource,
boolean)
Basically, the SQL server driver has a bug/issue with parameter metadata in
some queries. If you tell DBUtils to stop using parameter metadata, then it
should work without issue.
com.microsoft.sqlserver.jdbc.SQLServerException: Incorrect syntax near the
keyword 'WHERE'
--
Key: DBUTILS-102
URL: https://issues.apache.org/jira/browse/DBUTILS-102
Project: Commons DbUtils
Issue Type: Bug
Affects Versions: 1.4, 1.5
Environment: Windows 7; SQL Server 2012 Express Edition; Microsoft
JDBC Driver 4.0 for SQL Server
Reporter: Mario Vega
Priority: Critical
I have some sql with one parameter (typ). Using prepared statement works
good, but using the same sql and DBUtils throw exception. When i remove
parameter, DBUtils works good too. JUnit test below.
{code:java|title=TestDB.java}
package com.test;
import java.sql.Connection;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.sql.SQLException;
import java.util.ArrayList;
import java.util.List;
import org.apache.commons.dbutils.QueryRunner;
import org.apache.commons.dbutils.ResultSetHandler;
import org.apache.log4j.Logger;
import org.junit.Test;
public class TestDB {
Logger log = Logger.getLogger(TestDB.class);
@Test
public void dbutils() throws SQLException {
QueryRunner q = new QueryRunner(MyDataSource.getInstance());
ListImport2 l = q.query(select * from (select *,
row_number() over( order by id desc ) as row from import2 where typ = ? ) a
where row 10, new ResultSetHandlerListImport2(){
@Override
public ListImport2 handle(ResultSet rs) throws
SQLException {
ListImport2 l = new ArrayListImport2();
while(rs.next()) {
Import2 i = new Import2();
i.setTyp(rs.getString(typ));
i.setId(rs.getLong(id));
l.add(i);
}
return l;
}
}, new Object[]{TYPE1});
log.info(l);
}
@Test
public void jdbc() throws SQLException {
Connection c = MyDataSource.getInstance().getConnection();
PreparedStatement pst = c.prepareStatement(select * from
(select *, row_number() over( order by id desc ) as row from import2 where
typ = ? ) a where row 10);
pst.setString(1, TYPE1);
ResultSet rs = pst.executeQuery();
ListImport2 l = new ArrayListImport2();
while(rs.next()) {
Import2 i = new Import2();
i.setTyp(rs.getString(typ));
i.setId(rs.getLong(id));
l.add(i);
}
log.info(l);
}
class Import2 {
String typ;
Long id;
public String getTyp() {
return typ;
}
public void setTyp(String typ) {
this.typ = typ;
}
public Long getId() {
return id;
}
public void setId(Long id) {
this.id = id;
}
}
}
{code}
Exception:
{code:java}
java.sql.SQLException: com.microsoft.sqlserver.jdbc.SQLServerException:
Incorrect syntax near the keyword 'WHERE'. Query: select * from (select *,
row_number() over( order by id desc ) as row from import2 where typ = ? ) a
where row 10 Parameters: [TYPE1]
at
org.apache.commons.dbutils.AbstractQueryRunner.rethrow(AbstractQueryRunner.java:363)
at
org.apache.commons.dbutils.QueryRunner.query(QueryRunner.java:350)
at
org.apache.commons.dbutils.QueryRunner.query(QueryRunner.java:288)
at com.test.TestDB.dbutils(TestDB.java:24)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at
[jira] [Commented] (DBUTILS-101) QueryRunner fails to detect broken pmd
[ https://issues.apache.org/jira/browse/DBUTILS-101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13467022#comment-13467022 ] William R. Speirs commented on DBUTILS-101: --- Not that I know of. However, you can start one here: http://wiki.apache.org/commons/DbUtils The param meta data stuff is weird as I've noticed issues with some calls via SQLServer and not others, so tracking it down can sometimes be a pain. It is however almost always the first thing I try when I get a weird/unexpected error. QueryRunner fails to detect broken pmd -- Key: DBUTILS-101 URL: https://issues.apache.org/jira/browse/DBUTILS-101 Project: Commons DbUtils Issue Type: Improvement Affects Versions: 1.5 Reporter: Sébastien Le Ray Priority: Minor Original Estimate: 10m Remaining Estimate: 10m I recently fall across a strange issue with SQLServer JDBC driver and DBUtils. PreparedStatement#getParameterMetadata sometimes throw an SQLException which is not caught in fillParameter. The issue arises with pagination queries like SELECT * FROM ( SELECT ROW_NUMBER() OVER ( ORDER BY field1 ASC) AS RowNum, field1 as id, field2 as reference FROM MY_TABLE WHERE 1 = 1 AND field1 LIKE ?) as toPaginate WHERE RowNum = 1 AND RowNum = 50 the query is fine but getParameterMetaData throw an exception complaining about a syntax error near WHERE. Passing pmdKnownBroken to true solves this but stmt.getParameterMetaData(); should be wrapped to catch the exception to adjust pmdKnownBroken. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (DBUTILS-101) QueryRunner fails to detect broken pmd
[ https://issues.apache.org/jira/browse/DBUTILS-101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William R. Speirs closed DBUTILS-101. - Resolution: Not A Problem QueryRunner fails to detect broken pmd -- Key: DBUTILS-101 URL: https://issues.apache.org/jira/browse/DBUTILS-101 Project: Commons DbUtils Issue Type: Improvement Affects Versions: 1.5 Reporter: Sébastien Le Ray Priority: Minor Original Estimate: 10m Remaining Estimate: 10m I recently fall across a strange issue with SQLServer JDBC driver and DBUtils. PreparedStatement#getParameterMetadata sometimes throw an SQLException which is not caught in fillParameter. The issue arises with pagination queries like SELECT * FROM ( SELECT ROW_NUMBER() OVER ( ORDER BY field1 ASC) AS RowNum, field1 as id, field2 as reference FROM MY_TABLE WHERE 1 = 1 AND field1 LIKE ?) as toPaginate WHERE RowNum = 1 AND RowNum = 50 the query is fine but getParameterMetaData throw an exception complaining about a syntax error near WHERE. Passing pmdKnownBroken to true solves this but stmt.getParameterMetaData(); should be wrapped to catch the exception to adjust pmdKnownBroken. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DBUTILS-101) QueryRunner fails to detect broken pmd
[ https://issues.apache.org/jira/browse/DBUTILS-101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13466606#comment-13466606 ] William R. Speirs commented on DBUTILS-101: --- What is the exception? If it's simply an SQLException, then how can DBUtils distinguish between a where clause that is invalid and one where the pmdKnownBroken might just need adjusting? QueryRunner fails to detect broken pmd -- Key: DBUTILS-101 URL: https://issues.apache.org/jira/browse/DBUTILS-101 Project: Commons DbUtils Issue Type: Improvement Affects Versions: 1.5 Reporter: Sébastien Le Ray Priority: Minor Original Estimate: 10m Remaining Estimate: 10m I recently fall across a strange issue with SQLServer JDBC driver and DBUtils. PreparedStatement#getParameterMetadata sometimes throw an SQLException which is not caught in fillParameter. The issue arises with pagination queries like SELECT * FROM ( SELECT ROW_NUMBER() OVER ( ORDER BY field1 ASC) AS RowNum, field1 as id, field2 as reference FROM MY_TABLE WHERE 1 = 1 AND field1 LIKE ?) as toPaginate WHERE RowNum = 1 AND RowNum = 50 the query is fine but getParameterMetaData throw an exception complaining about a syntax error near WHERE. Passing pmdKnownBroken to true solves this but stmt.getParameterMetaData(); should be wrapped to catch the exception to adjust pmdKnownBroken. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DBUTILS-97) Add an AbstractResultSetHandler implementation in order to reduce redundant 'resultSet' variable invocation
[
https://issues.apache.org/jira/browse/DBUTILS-97?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13460395#comment-13460395
]
William R. Speirs commented on DBUTILS-97:
--
Sounds good, go for it! Thanks...
Add an AbstractResultSetHandler implementation in order to reduce redundant
'resultSet' variable invocation
---
Key: DBUTILS-97
URL: https://issues.apache.org/jira/browse/DBUTILS-97
Project: Commons DbUtils
Issue Type: New Feature
Affects Versions: 1.6
Reporter: Simone Tripodi
Assignee: Simone Tripodi
Fix For: 1.6
Attachments: DBUTILS-97.patch
According to the DRY principle (Don't Repeat Yourself), repeating
{{resultSet}} variable inside the {{ResultSetHandler#handle(ResultSet)}} over
and over for each iteration can get a little tedious.
It would be helpful adding a support class, named
{{AbstractResultSetHandler}}, which implicitly gives users access to
{{ResultSet}}'s methods. _For example_, we could extend
{{AbstractResultSetHandler}} and rewrite the mapping below:
{code}
new ResultSetHandlerCollectionMapString, Object {
@Override
public CollectionMapString, Object handle(ResultSet rs) throws
SQLException {
CollectionMapString, Object result = new LinkedListMapString,
Object();
while (rs.next()) {
MapString, Object current = new HashMapString, Object();
for (int i = 1; i = rs.getMetaData().getColumnCount(); i++) {
current.put(rs.getMetaData().getColumnName(i),
rs.getObject(i));
}
result.add(current);
}
return result;
}
}
{code}
as:
{code}
new AbstractResultSetHandlerCollectionMapString, Object {
@Override
protected CollectionMapString, Object handle() throws SQLException {
CollectionMapString, Object result = new LinkedListMapString,
Object();
while (next()) {
MapString, Object current = new HashMapString, Object();
for (int i = 1; i = getMetaData().getColumnCount(); i++) {
current.put(getMetaData().getColumnName(i), getObject(i));
}
result.add(current);
}
return result;
}
}
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (DBUTILS-99) Create QueryRunner Factory
William R. Speirs created DBUTILS-99: Summary: Create QueryRunner Factory Key: DBUTILS-99 URL: https://issues.apache.org/jira/browse/DBUTILS-99 Project: Commons DbUtils Issue Type: Improvement Affects Versions: 1.5 Reporter: William R. Speirs Assignee: William R. Speirs Priority: Minor Currently there is no good way to use dependency injection with QueryRunners. Creating a simple factory class to allow for easy injection (and therefore easier unit test creation) should solve this problem. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DBUTILS-99) Create QueryRunner Factory
[
https://issues.apache.org/jira/browse/DBUTILS-99?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13437922#comment-13437922
]
William R. Speirs commented on DBUTILS-99:
--
Maybe this is my mis-understanding of dependency injection. I don't use Guice
and simply inject my dependencies via the constructor, so something like:
{code:borderStyle=solid}
public MyClass(QueryRunnerFactory factory) {
this.factory = factory;
}
{code}
This way I can simply mock up an instance of QueryRunnerFactory in my unit
tests and provide fake results from the DB. Maybe this isn't useful for others?
Create QueryRunner Factory
--
Key: DBUTILS-99
URL: https://issues.apache.org/jira/browse/DBUTILS-99
Project: Commons DbUtils
Issue Type: Improvement
Affects Versions: 1.5
Reporter: William R. Speirs
Assignee: William R. Speirs
Priority: Minor
Currently there is no good way to use dependency injection with QueryRunners.
Creating a simple factory class to allow for easy injection (and therefore
easier unit test creation) should solve this problem.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DBUTILS-99) Create QueryRunner Factory
[ https://issues.apache.org/jira/browse/DBUTILS-99?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13437966#comment-13437966 ] William R. Speirs commented on DBUTILS-99: -- I guess this should have hit the mailing list before JIRA, but what do people think... worth adding the class? Or, not something we want to bloat the library with because as both Simone and Moandji pointed out, frameworks like Spring and Guice can do this for people. Create QueryRunner Factory -- Key: DBUTILS-99 URL: https://issues.apache.org/jira/browse/DBUTILS-99 Project: Commons DbUtils Issue Type: Improvement Affects Versions: 1.5 Reporter: William R. Speirs Assignee: William R. Speirs Priority: Minor Currently there is no good way to use dependency injection with QueryRunners. Creating a simple factory class to allow for easy injection (and therefore easier unit test creation) should solve this problem. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DBUTILS-99) Create QueryRunner Factory
[ https://issues.apache.org/jira/browse/DBUTILS-99?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13438366#comment-13438366 ] William R. Speirs commented on DBUTILS-99: -- I'm slightly embarrassed to say that even though I was the one who created the AbstractQueryRunner, I had forgotten that was reusable and thread safe. For some reason I had the impression that reusing a QueryRunner was a bad idea. Time to go remove some code at work :-) Create QueryRunner Factory -- Key: DBUTILS-99 URL: https://issues.apache.org/jira/browse/DBUTILS-99 Project: Commons DbUtils Issue Type: Improvement Affects Versions: 1.5 Reporter: William R. Speirs Assignee: William R. Speirs Priority: Minor Fix For: 1.5 Currently there is no good way to use dependency injection with QueryRunners. Creating a simple factory class to allow for easy injection (and therefore easier unit test creation) should solve this problem. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (DBUTILS-99) Create QueryRunner Factory
[ https://issues.apache.org/jira/browse/DBUTILS-99?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William R. Speirs resolved DBUTILS-99. -- Resolution: Not A Problem Fix Version/s: 1.5 A factory class is not needed for QueryRunner as they can be safely reused and are thread safe. Create QueryRunner Factory -- Key: DBUTILS-99 URL: https://issues.apache.org/jira/browse/DBUTILS-99 Project: Commons DbUtils Issue Type: Improvement Affects Versions: 1.5 Reporter: William R. Speirs Assignee: William R. Speirs Priority: Minor Fix For: 1.5 Currently there is no good way to use dependency injection with QueryRunners. Creating a simple factory class to allow for easy injection (and therefore easier unit test creation) should solve this problem. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (DBUTILS-87) Return generated key on insert
[ https://issues.apache.org/jira/browse/DBUTILS-87?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William R. Speirs resolved DBUTILS-87. -- Resolution: Implemented Fix Version/s: 1.6 Code submitted, r1370883 Return generated key on insert -- Key: DBUTILS-87 URL: https://issues.apache.org/jira/browse/DBUTILS-87 Project: Commons DbUtils Issue Type: New Feature Reporter: Moandji Ezana Assignee: William R. Speirs Fix For: 1.6 Attachments: AsyncQueryRunner_add_insert_methods.patch, QueryRunner_insert.txt It would be useful to have an insert method on QueryRunner that returns the id of the new record. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DBUTILS-96) dynamic load jdbc jars use Dbutils,it say No suitable driver found for jdbc
[
https://issues.apache.org/jira/browse/DBUTILS-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13429329#comment-13429329
]
William R. Speirs commented on DBUTILS-96:
--
v3 looks good. I'd say commit, post the SVN rev number here, and resolve.
Thanks!
dynamic load jdbc jars use Dbutils,it say No suitable driver found for jdbc
Key: DBUTILS-96
URL: https://issues.apache.org/jira/browse/DBUTILS-96
Project: Commons DbUtils
Issue Type: Bug
Environment: jdk 1.6
Reporter: yuyf
Assignee: Simone Tripodi
Attachments: DBUTILS-96.patch, DBUTILS-96_v2.patch,
DBUTILS-96_v3.patch, dbutils-96.tar.gz, dynamicloadjar.zip, mysql.properties
By this way(use Dbutil get connect),it will say: {{No suitable driver found
for jdbc:mysql://127.0.0.1:3306/xxx}}
{code}
urls = new URL[1];
urls[0] = new File(d:\mysql_connector_5.1.15_bin.jar).toURL();
URLClassLoader urlClassLoader= new URLClassLoader(urls,
ClassLoader.getSystemClassLoader())
DbUtils.loadDriver(urlClassLoader, driver);
Properties conProps = new Properties();
conProps.put(user, user);
conProps.put(password, pwd);
conProps.put(defaultRowPrefetch, 20);
scanedConnection = DriverManager.getConnection(url, conProps);
{code}
but by this way (use jdbc's api get connect),it's ok
{code}
try {
URL jdbcDriverURL = new
File(d:\\mysql_connector_5.1.15_bin.jar).toURL();
URL[] urls = new URL[1];
urls[0] = jdbcDriverURL;
URLClassLoader urlclassLoader = new URLClassLoader(urls,
ClassLoader.getSystemClassLoader());
try {
java.sql.Driver driverd = (java.sql.Driver)
urlclassLoader.loadClass(driver).newInstance();
System.out.println(driverd.toString());
Properties props = new Properties();
props.setProperty(user, theUser);
props.setProperty(password, thePw);
try {
c = driverd.connect(dbUrl, props);
} catch (SQLException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
} catch (InstantiationException e) {
// TODO Auto-generated catch block
e.printStackTrace();
} catch (IllegalAccessException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
} catch (MalformedURLException e1) {
// TODO Auto-generated catch block
e1.printStackTrace();
}
{code}
is this a bug or my useing falut?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DBUTILS-97) Add an AbstractResultSetHandler implementation in order to reduce redundant 'resultSet' variable invocation
[
https://issues.apache.org/jira/browse/DBUTILS-97?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13429334#comment-13429334
]
William R. Speirs commented on DBUTILS-97:
--
I'm not sure if we want to set rs to null in the finally. Wouldn't this be more
of a use-once object? Couldn't there be threading issues if the same instance
of AbstractResultSetHandler were used more than once with different result
sets? (I'm not sure how that would happen, but...)
Add an AbstractResultSetHandler implementation in order to reduce redundant
'resultSet' variable invocation
---
Key: DBUTILS-97
URL: https://issues.apache.org/jira/browse/DBUTILS-97
Project: Commons DbUtils
Issue Type: New Feature
Affects Versions: 1.6
Reporter: Simone Tripodi
Assignee: Simone Tripodi
Fix For: 1.6
Attachments: DBUTILS-97.patch
According to the DRY principle (Don't Repeat Yourself), repeating
{{resultSet}} variable inside the {{ResultSetHandler#handle(ResultSet)}} over
and over for each iteration can get a little tedious.
It would be helpful adding a support class, named
{{AbstractResultSetHandler}}, which implicitly gives users access to
{{ResultSet}}'s methods. _For example_, we could extend
{{AbstractResultSetHandler}} and rewrite the mapping below:
{code}
new ResultSetHandlerCollectionMapString, Object {
@Override
public CollectionMapString, Object handle(ResultSet rs) throws
SQLException {
CollectionMapString, Object result = new LinkedListMapString,
Object();
while (rs.next()) {
MapString, Object current = new HashMapString, Object();
for (int i = 1; i = rs.getMetaData().getColumnCount(); i++) {
current.put(rs.getMetaData().getColumnName(i),
rs.getObject(i));
}
result.add(current);
}
return result;
}
}
{code}
as:
{code}
new AbstractResultSetHandlerCollectionMapString, Object {
@Override
protected CollectionMapString, Object handle() throws SQLException {
CollectionMapString, Object result = new LinkedListMapString,
Object();
while (next()) {
MapString, Object current = new HashMapString, Object();
for (int i = 1; i = getMetaData().getColumnCount(); i++) {
current.put(getMetaData().getColumnName(i), getObject(i));
}
result.add(current);
}
return result;
}
}
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DBUTILS-96) dynamic load jdbc jars use Dbutils,it say No suitable driver found for jdbc
[
https://issues.apache.org/jira/browse/DBUTILS-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13423104#comment-13423104
]
William R. Speirs commented on DBUTILS-96:
--
This is most likely your use. I noticed in the non-working one you have the
path as d:\mysql_connector_5.1.15_bin.jar but in the working one you have
d:mysql_connector_5.1.15_bin.jar. I'm guessing the issue is the improperly
escaped \m
dynamic load jdbc jars use Dbutils,it say No suitable driver found for jdbc
Key: DBUTILS-96
URL: https://issues.apache.org/jira/browse/DBUTILS-96
Project: Commons DbUtils
Issue Type: Bug
Environment: jdk 1.6
Reporter: yuyf
By this way(use Dbutil get connect),it will say:No suitable driver found for
jdbc:mysql://127.0.0.1:3306/xxx
urls = new URL[1];
urls[0] = new File(d:\mysql_connector_5.1.15_bin.jar).toURL();
URLClassLoader urlClassLoader= new
URLClassLoader(urls,ClassLoader.getSystemClassLoader())
DbUtils.loadDriver(urlClassLoader,driver);
Properties conProps = new Properties();
conProps.put(user, user);
conProps.put(password, pwd);
conProps.put(defaultRowPrefetch, 20);
scanedConnection = DriverManager.getConnection(url, conProps);
but by this way (use jdbc's api get connect),it's ok
try {
URL jdbcDriverURL = new File(d:\\mysql_connector_5.1.15_bin.jar).toURL();
URL[] urls = new URL[1];
urls[0] = jdbcDriverURL;
URLClassLoader urlclassLoader = new
URLClassLoader(urls,ClassLoader.getSystemClassLoader());
try {
java.sql.Driver driverd = (java.sql.Driver)
urlclassLoader.loadClass(driver).newInstance();
System.out.println(driverd.toString());
Properties props = new Properties();
props.setProperty(user, theUser);
props.setProperty(password, thePw);
try {
c = driverd.connect(dbUrl, props);
} catch (SQLException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
} catch (InstantiationException e) {
// TODO Auto-generated catch block
e.printStackTrace();
} catch (IllegalAccessException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}//
} catch (MalformedURLException e1) {
// TODO Auto-generated catch block
e1.printStackTrace();
}
is this a bug or my useing falut?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DBUTILS-78) Add asynchronous batch, query, and update calls
[ https://issues.apache.org/jira/browse/DBUTILS-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13114691#comment-13114691 ] William R. Speirs commented on DBUTILS-78: -- Overall looks good! A few things: 1) I cannot think of a case where the Callable which is returned wouldn't simply be placed on some ExecutorService, but just because I cannot think of a case doesn't mean someone might not want to do it. If we go with this patch we force people's hand to use an ExecutorService. Again, I don't think it's a big deal, but I'd to get other people's thoughts. 2) The tests which are failing are all failing because of a check to see if the statement hasn't been closed after calling batch, update, or query before calling get(). However, now that we're using an ExecutorService this get() call is being executed for us, so the check is no longer valid. I've removed the check from the test case so that all of the tests now pass. (Note: we still check to make sure the statements are all properly closed at the end.) I attached a new patch which includes these changes: DBUTILS-78_Future_v2.patch Bill- Add asynchronous batch, query, and update calls --- Key: DBUTILS-78 URL: https://issues.apache.org/jira/browse/DBUTILS-78 Project: Commons DbUtils Issue Type: New Feature Reporter: William R. Speirs Priority: Minor Fix For: 1.4 Attachments: 08_16_2011.diff, AsyncQueryRunner.java, AsyncQueryRunnerTest.java, DBUTILS-78_Future.patch, DBUTILS-78_Future_v2.patch, async.diff, pom.diff I propose a new QueryRunner class, AsyncQueryRunner, which changes the return type of batch, query, and update methods. Instead of returning their respective return types, the methods would return a RunnableFuture. This would allow callers to either execute the RunnableFuture in a thread or via an CompletionService like the ExecutorCompletionService. I have attached a first cut at this class. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DBUTILS-78) Add asynchronous batch, query, and update calls
[ https://issues.apache.org/jira/browse/DBUTILS-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William R. Speirs updated DBUTILS-78: - Attachment: DBUTILS-78_Future_v2.patch Add asynchronous batch, query, and update calls --- Key: DBUTILS-78 URL: https://issues.apache.org/jira/browse/DBUTILS-78 Project: Commons DbUtils Issue Type: New Feature Reporter: William R. Speirs Priority: Minor Fix For: 1.4 Attachments: 08_16_2011.diff, AsyncQueryRunner.java, AsyncQueryRunnerTest.java, DBUTILS-78_Future.patch, DBUTILS-78_Future_v2.patch, async.diff, pom.diff I propose a new QueryRunner class, AsyncQueryRunner, which changes the return type of batch, query, and update methods. Instead of returning their respective return types, the methods would return a RunnableFuture. This would allow callers to either execute the RunnableFuture in a thread or via an CompletionService like the ExecutorCompletionService. I have attached a first cut at this class. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DBUTILS-78) Add asynchronous batch, query, and update calls
[ https://issues.apache.org/jira/browse/DBUTILS-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13114701#comment-13114701 ] William R. Speirs commented on DBUTILS-78: -- My use case simply takes the result of my patch, Callable, and submits it to an ExecutorService. It never occurred to me to simply provide the API with the ExecutorService and let it do the submission. Anyone else reading this have thoughts on this? Otherwise, I like the patch! Add asynchronous batch, query, and update calls --- Key: DBUTILS-78 URL: https://issues.apache.org/jira/browse/DBUTILS-78 Project: Commons DbUtils Issue Type: New Feature Reporter: William R. Speirs Priority: Minor Fix For: 1.4 Attachments: 08_16_2011.diff, AsyncQueryRunner.java, AsyncQueryRunnerTest.java, DBUTILS-78_Future.patch, DBUTILS-78_Future_v2.patch, async.diff, pom.diff I propose a new QueryRunner class, AsyncQueryRunner, which changes the return type of batch, query, and update methods. Instead of returning their respective return types, the methods would return a RunnableFuture. This would allow callers to either execute the RunnableFuture in a thread or via an CompletionService like the ExecutorCompletionService. I have attached a first cut at this class. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DBUTILS-78) Add asynchronous batch, query, and update calls
[ https://issues.apache.org/jira/browse/DBUTILS-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13114729#comment-13114729 ] William R. Speirs commented on DBUTILS-78: -- Hmmm... I'm on a Windows box and used TortoiseSVN and created the patch as I normally do. It is a patch on top of your patch... essentially I applied your patch, made changes, and then created another patch. I can try it again and re-attach, but I've created patches this way before and they've worked so I'm not really sure... Add asynchronous batch, query, and update calls --- Key: DBUTILS-78 URL: https://issues.apache.org/jira/browse/DBUTILS-78 Project: Commons DbUtils Issue Type: New Feature Reporter: William R. Speirs Priority: Minor Fix For: 1.4 Attachments: 08_16_2011.diff, AsyncQueryRunner.java, AsyncQueryRunnerTest.java, DBUTILS-78_Future.patch, DBUTILS-78_Future_v2.patch, async.diff, pom.diff I propose a new QueryRunner class, AsyncQueryRunner, which changes the return type of batch, query, and update methods. Instead of returning their respective return types, the methods would return a RunnableFuture. This would allow callers to either execute the RunnableFuture in a thread or via an CompletionService like the ExecutorCompletionService. I have attached a first cut at this class. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DBUTILS-78) Add asynchronous batch, query, and update calls
[ https://issues.apache.org/jira/browse/DBUTILS-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13114730#comment-13114730 ] William R. Speirs commented on DBUTILS-78: -- Try DBUTILS-78_Future_v2.diff Add asynchronous batch, query, and update calls --- Key: DBUTILS-78 URL: https://issues.apache.org/jira/browse/DBUTILS-78 Project: Commons DbUtils Issue Type: New Feature Reporter: William R. Speirs Priority: Minor Fix For: 1.4 Attachments: 08_16_2011.diff, AsyncQueryRunner.java, AsyncQueryRunnerTest.java, DBUTILS-78_Future.patch, DBUTILS-78_Future_v2.diff, DBUTILS-78_Future_v2.patch, async.diff, pom.diff I propose a new QueryRunner class, AsyncQueryRunner, which changes the return type of batch, query, and update methods. Instead of returning their respective return types, the methods would return a RunnableFuture. This would allow callers to either execute the RunnableFuture in a thread or via an CompletionService like the ExecutorCompletionService. I have attached a first cut at this class. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DBUTILS-78) Add asynchronous batch, query, and update calls
[ https://issues.apache.org/jira/browse/DBUTILS-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William R. Speirs updated DBUTILS-78: - Attachment: DBUTILS-78_Future_v2.diff Add asynchronous batch, query, and update calls --- Key: DBUTILS-78 URL: https://issues.apache.org/jira/browse/DBUTILS-78 Project: Commons DbUtils Issue Type: New Feature Reporter: William R. Speirs Priority: Minor Fix For: 1.4 Attachments: 08_16_2011.diff, AsyncQueryRunner.java, AsyncQueryRunnerTest.java, DBUTILS-78_Future.patch, DBUTILS-78_Future_v2.diff, DBUTILS-78_Future_v2.patch, async.diff, pom.diff I propose a new QueryRunner class, AsyncQueryRunner, which changes the return type of batch, query, and update methods. Instead of returning their respective return types, the methods would return a RunnableFuture. This would allow callers to either execute the RunnableFuture in a thread or via an CompletionService like the ExecutorCompletionService. I have attached a first cut at this class. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DBUTILS-78) Add asynchronous batch, query, and update calls
[ https://issues.apache.org/jira/browse/DBUTILS-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13114369#comment-13114369 ] William R. Speirs commented on DBUTILS-78: -- OK, I will take a look tomorrow. Bill- https://issues.apache.org/jira/browse/DBUTILS-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel] because there are test failures. working and committing it - or feel free to submit a patch yourself and than I can apply it, just let me know. AsyncQueryRunnerTest.java, DBUTILS-78_Future.patch, async.diff, pom.diff return type of batch, query, and update methods. Instead of returning their respective return types, the methods would return a RunnableFuture. This would allow callers to either execute the RunnableFuture in a thread or via an CompletionService like the ExecutorCompletionService. Add asynchronous batch, query, and update calls --- Key: DBUTILS-78 URL: https://issues.apache.org/jira/browse/DBUTILS-78 Project: Commons DbUtils Issue Type: New Feature Reporter: William R. Speirs Priority: Minor Fix For: 1.4 Attachments: 08_16_2011.diff, AsyncQueryRunner.java, AsyncQueryRunnerTest.java, DBUTILS-78_Future.patch, async.diff, pom.diff I propose a new QueryRunner class, AsyncQueryRunner, which changes the return type of batch, query, and update methods. Instead of returning their respective return types, the methods would return a RunnableFuture. This would allow callers to either execute the RunnableFuture in a thread or via an CompletionService like the ExecutorCompletionService. I have attached a first cut at this class. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DBUTILS-78) Add asynchronous batch, query, and update calls
[ https://issues.apache.org/jira/browse/DBUTILS-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William R. Speirs updated DBUTILS-78: - Attachment: 08_16_2011.diff Add asynchronous batch, query, and update calls --- Key: DBUTILS-78 URL: https://issues.apache.org/jira/browse/DBUTILS-78 Project: Commons DbUtils Issue Type: New Feature Reporter: William R. Speirs Priority: Minor Fix For: 1.4 Attachments: 08_16_2011.diff, AsyncQueryRunner.java, AsyncQueryRunnerTest.java, async.diff, pom.diff I propose a new QueryRunner class, AsyncQueryRunner, which changes the return type of batch, query, and update methods. Instead of returning their respective return types, the methods would return a RunnableFuture. This would allow callers to either execute the RunnableFuture in a thread or via an CompletionService like the ExecutorCompletionService. I have attached a first cut at this class. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DBUTILS-78) Add asynchronous batch, query, and update calls
[ https://issues.apache.org/jira/browse/DBUTILS-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13085699#comment-13085699 ] William R. Speirs commented on DBUTILS-78: -- Henri, good eyes! The public - private and closing the null connections were all mistakes. I also updated the example to break it up into two try/catch blocks. If you think it needs further changes, go for it. These changes are attached as 08_16_2011.diff. The only other thing would be dropping the deprecated methods from the QueryRunner class. Thoughts on that? Thanks... Add asynchronous batch, query, and update calls --- Key: DBUTILS-78 URL: https://issues.apache.org/jira/browse/DBUTILS-78 Project: Commons DbUtils Issue Type: New Feature Reporter: William R. Speirs Priority: Minor Fix For: 1.4 Attachments: 08_16_2011.diff, AsyncQueryRunner.java, AsyncQueryRunnerTest.java, async.diff, pom.diff I propose a new QueryRunner class, AsyncQueryRunner, which changes the return type of batch, query, and update methods. Instead of returning their respective return types, the methods would return a RunnableFuture. This would allow callers to either execute the RunnableFuture in a thread or via an CompletionService like the ExecutorCompletionService. I have attached a first cut at this class. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DBUTILS-78) Add asynchronous batch, query, and update calls
[ https://issues.apache.org/jira/browse/DBUTILS-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13084129#comment-13084129 ] William R. Speirs commented on DBUTILS-78: -- While I'm refactoring this, is it OK to remove the deprecated methods in QueryRunner? Add asynchronous batch, query, and update calls --- Key: DBUTILS-78 URL: https://issues.apache.org/jira/browse/DBUTILS-78 Project: Commons DbUtils Issue Type: New Feature Reporter: William R. Speirs Priority: Minor Fix For: 1.4 Attachments: AsyncQueryRunner.java, AsyncQueryRunnerTest.java, pom.diff I propose a new QueryRunner class, AsyncQueryRunner, which changes the return type of batch, query, and update methods. Instead of returning their respective return types, the methods would return a RunnableFuture. This would allow callers to either execute the RunnableFuture in a thread or via an CompletionService like the ExecutorCompletionService. I have attached a first cut at this class. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DBUTILS-78) Add asynchronous batch, query, and update calls
[ https://issues.apache.org/jira/browse/DBUTILS-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William R. Speirs updated DBUTILS-78: - Attachment: async.diff Add asynchronous batch, query, and update calls --- Key: DBUTILS-78 URL: https://issues.apache.org/jira/browse/DBUTILS-78 Project: Commons DbUtils Issue Type: New Feature Reporter: William R. Speirs Priority: Minor Fix For: 1.4 Attachments: AsyncQueryRunner.java, AsyncQueryRunnerTest.java, async.diff, pom.diff I propose a new QueryRunner class, AsyncQueryRunner, which changes the return type of batch, query, and update methods. Instead of returning their respective return types, the methods would return a RunnableFuture. This would allow callers to either execute the RunnableFuture in a thread or via an CompletionService like the ExecutorCompletionService. I have attached a first cut at this class. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DBUTILS-78) Add asynchronous batch, query, and update calls
[ https://issues.apache.org/jira/browse/DBUTILS-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13084179#comment-13084179 ] William R. Speirs commented on DBUTILS-78: -- I attached another patch which does the following: - Adds AbstractQueryRunner class - Removes common methods from QueryRunner and AsyncQueryRunner, both now extend AbstractQueryRunner - Updated the QueryRunner unit test to use Mockito; now with 74% code coverage (doesn't hit deprecated methods) Add asynchronous batch, query, and update calls --- Key: DBUTILS-78 URL: https://issues.apache.org/jira/browse/DBUTILS-78 Project: Commons DbUtils Issue Type: New Feature Reporter: William R. Speirs Priority: Minor Fix For: 1.4 Attachments: AsyncQueryRunner.java, AsyncQueryRunnerTest.java, async.diff, pom.diff I propose a new QueryRunner class, AsyncQueryRunner, which changes the return type of batch, query, and update methods. Instead of returning their respective return types, the methods would return a RunnableFuture. This would allow callers to either execute the RunnableFuture in a thread or via an CompletionService like the ExecutorCompletionService. I have attached a first cut at this class. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DBUTILS-79) fillStatement doesn't complain when there are too few parameters
[ https://issues.apache.org/jira/browse/DBUTILS-79?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13084181#comment-13084181 ] William R. Speirs commented on DBUTILS-79: -- If the latest patch I submitted to DBUTILS-78 is applied, it takes care of this issue. fillStatement doesn't complain when there are too few parameters Key: DBUTILS-79 URL: https://issues.apache.org/jira/browse/DBUTILS-79 Project: Commons DbUtils Issue Type: Bug Affects Versions: 1.3 Reporter: William R. Speirs Fix For: 1.4 Unless I'm reading the code incorrectly, it appears that the fillStatement function does not complain if you provide too few parameters. For example, if you supply an SQL statement like: select * from blah where ? = ?; but only provide a single parameter test, fillStatement returns without issue. However, only the first ? is actually set. Granted, this will almost always cause an exception to be thrown by the driver, but since there is already a check for too many parameters, why not check for too few as well? (FYI: I came across this bug, and a few others in my AsyncQueryRunner implementation, while re-writing the unit tests to use Mockito.) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DBUTILS-78) Add asynchronous batch, query, and update calls
[ https://issues.apache.org/jira/browse/DBUTILS-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William R. Speirs updated DBUTILS-78: - Attachment: (was: async.diff) Add asynchronous batch, query, and update calls --- Key: DBUTILS-78 URL: https://issues.apache.org/jira/browse/DBUTILS-78 Project: Commons DbUtils Issue Type: New Feature Reporter: William R. Speirs Priority: Minor Fix For: 1.4 Attachments: AsyncQueryRunner.java, AsyncQueryRunnerTest.java, pom.diff I propose a new QueryRunner class, AsyncQueryRunner, which changes the return type of batch, query, and update methods. Instead of returning their respective return types, the methods would return a RunnableFuture. This would allow callers to either execute the RunnableFuture in a thread or via an CompletionService like the ExecutorCompletionService. I have attached a first cut at this class. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DBUTILS-78) Add asynchronous batch, query, and update calls
[ https://issues.apache.org/jira/browse/DBUTILS-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William R. Speirs updated DBUTILS-78: - Attachment: async.diff Updated async.diff to include an update to the AsyncQueryRunner class and an example in the examples.xml file. Add asynchronous batch, query, and update calls --- Key: DBUTILS-78 URL: https://issues.apache.org/jira/browse/DBUTILS-78 Project: Commons DbUtils Issue Type: New Feature Reporter: William R. Speirs Priority: Minor Fix For: 1.4 Attachments: AsyncQueryRunner.java, AsyncQueryRunnerTest.java, async.diff, pom.diff I propose a new QueryRunner class, AsyncQueryRunner, which changes the return type of batch, query, and update methods. Instead of returning their respective return types, the methods would return a RunnableFuture. This would allow callers to either execute the RunnableFuture in a thread or via an CompletionService like the ExecutorCompletionService. I have attached a first cut at this class. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DBUTILS-53) Set Derby up as a unit test database
[ https://issues.apache.org/jira/browse/DBUTILS-53?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13082350#comment-13082350 ] William R. Speirs commented on DBUTILS-53: -- Thoughts on merging the unit tests for AsyncQueryRunner into QueryRunner? Set Derby up as a unit test database Key: DBUTILS-53 URL: https://issues.apache.org/jira/browse/DBUTILS-53 Project: Commons DbUtils Issue Type: Task Reporter: Henri Yandell Or hsqldb. I used Derby for Taglibs to test the sql tags and it worked well enough. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (DBUTILS-78) Add asynchronous batch, query, and update calls
[ https://issues.apache.org/jira/browse/DBUTILS-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13082349#comment-13082349 ] William R. Speirs edited comment on DBUTILS-78 at 8/10/11 2:03 PM: --- 1) Yea, we'll need Java 6 for the future stuff. Wasn't sure what the project's posture on that is. 2) Not a problem... documentation is key. However, I don't think this patch should be accepted as-is :-) There is a LOT of duplicate code in my patch. I did this because I didn't want to mess with the QueryRunner code if everyone thought my idea was stupid. However, there are a number of methods in the AsyncQueryRunner are improved from the QueryRunner (see DBUTILS-79). I propose that we create a base or abstract class which both QueryRunner and AsyncQueryRunner extend. Thoughts? was (Author: wspeirs): 1) Yea, we'll need Java 6 for the future stuff. Wasn't sure what the project's posture on that is. 2) Not a problem... documentation is key. However, I don't think this patch should be accepted as-is :-) There is a LOT of duplicate code in my patch. I did this because I didn't want to mess with the QuerryRunner code if everyone thought my idea was stupid. However, there are a number of methods in the AsyncQuerryRunner are improved from the QuerryRunner (see DBUTILS-79). I propose that we create a base or abstract class which both QuerryRunner and AsyncQuerryRunner extend. Thoughts? Add asynchronous batch, query, and update calls --- Key: DBUTILS-78 URL: https://issues.apache.org/jira/browse/DBUTILS-78 Project: Commons DbUtils Issue Type: New Feature Reporter: William R. Speirs Priority: Minor Fix For: 1.4 Attachments: AsyncQueryRunner.java, AsyncQueryRunnerTest.java, pom.diff I propose a new QueryRunner class, AsyncQueryRunner, which changes the return type of batch, query, and update methods. Instead of returning their respective return types, the methods would return a RunnableFuture. This would allow callers to either execute the RunnableFuture in a thread or via an CompletionService like the ExecutorCompletionService. I have attached a first cut at this class. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DBUTILS-78) Add asynchronous batch, query, and update calls
[ https://issues.apache.org/jira/browse/DBUTILS-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13081657#comment-13081657 ] William R. Speirs commented on DBUTILS-78: -- Any idea if/when this change will be integrated? Just looking for some feedback on the idea... Thanks! Add asynchronous batch, query, and update calls --- Key: DBUTILS-78 URL: https://issues.apache.org/jira/browse/DBUTILS-78 Project: Commons DbUtils Issue Type: New Feature Reporter: William R. Speirs Priority: Minor Fix For: 1.4 Attachments: AsyncQueryRunner.java, AsyncQueryRunnerTest.java, pom.diff I propose a new QueryRunner class, AsyncQueryRunner, which changes the return type of batch, query, and update methods. Instead of returning their respective return types, the methods would return a RunnableFuture. This would allow callers to either execute the RunnableFuture in a thread or via an CompletionService like the ExecutorCompletionService. I have attached a first cut at this class. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DBUTILS-78) Add asynchronous batch, query, and update calls
[ https://issues.apache.org/jira/browse/DBUTILS-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William R. Speirs updated DBUTILS-78: - Attachment: pom.diff Add asynchronous batch, query, and update calls --- Key: DBUTILS-78 URL: https://issues.apache.org/jira/browse/DBUTILS-78 Project: Commons DbUtils Issue Type: New Feature Reporter: William R. Speirs Priority: Minor Fix For: 1.4 Attachments: AsyncQueryRunner.java, AsyncQueryRunnerTest.java, pom.diff I propose a new QueryRunner class, AsyncQueryRunner, which changes the return type of batch, query, and update methods. Instead of returning their respective return types, the methods would return a RunnableFuture. This would allow callers to either execute the RunnableFuture in a thread or via an CompletionService like the ExecutorCompletionService. I have attached a first cut at this class. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DBUTILS-78) Add asynchronous batch, query, and update calls
[ https://issues.apache.org/jira/browse/DBUTILS-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William R. Speirs updated DBUTILS-78: - Attachment: AsyncQueryRunner.java Add asynchronous batch, query, and update calls --- Key: DBUTILS-78 URL: https://issues.apache.org/jira/browse/DBUTILS-78 Project: Commons DbUtils Issue Type: New Feature Reporter: William R. Speirs Priority: Minor Fix For: 1.4 Attachments: AsyncQueryRunner.java, AsyncQueryRunnerTest.java I propose a new QueryRunner class, AsyncQueryRunner, which changes the return type of batch, query, and update methods. Instead of returning their respective return types, the methods would return a RunnableFuture. This would allow callers to either execute the RunnableFuture in a thread or via an CompletionService like the ExecutorCompletionService. I have attached a first cut at this class. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DBUTILS-78) Add asynchronous batch, query, and update calls
[ https://issues.apache.org/jira/browse/DBUTILS-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William R. Speirs updated DBUTILS-78: - Attachment: (was: AsyncQueryRunner.java) Add asynchronous batch, query, and update calls --- Key: DBUTILS-78 URL: https://issues.apache.org/jira/browse/DBUTILS-78 Project: Commons DbUtils Issue Type: New Feature Reporter: William R. Speirs Priority: Minor Fix For: 1.4 Attachments: AsyncQueryRunner.java, AsyncQueryRunnerTest.java I propose a new QueryRunner class, AsyncQueryRunner, which changes the return type of batch, query, and update methods. Instead of returning their respective return types, the methods would return a RunnableFuture. This would allow callers to either execute the RunnableFuture in a thread or via an CompletionService like the ExecutorCompletionService. I have attached a first cut at this class. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DBUTILS-78) Add asynchronous batch, query, and update calls
[ https://issues.apache.org/jira/browse/DBUTILS-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William R. Speirs updated DBUTILS-78: - Attachment: AsyncQueryRunnerTest.java Add asynchronous batch, query, and update calls --- Key: DBUTILS-78 URL: https://issues.apache.org/jira/browse/DBUTILS-78 Project: Commons DbUtils Issue Type: New Feature Reporter: William R. Speirs Priority: Minor Fix For: 1.4 Attachments: AsyncQueryRunner.java, AsyncQueryRunnerTest.java I propose a new QueryRunner class, AsyncQueryRunner, which changes the return type of batch, query, and update methods. Instead of returning their respective return types, the methods would return a RunnableFuture. This would allow callers to either execute the RunnableFuture in a thread or via an CompletionService like the ExecutorCompletionService. I have attached a first cut at this class. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DBUTILS-78) Add asynchronous batch, query, and update calls
[ https://issues.apache.org/jira/browse/DBUTILS-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13073197#comment-13073197 ] William R. Speirs commented on DBUTILS-78: -- I wrote unit tests for the AsyncQueryRunner code. I am getting 73% coverage over the AsyncQueryRunner class. The only things that are not covered are a few exceptions in a few places; however, all methods are covered. I also replaced the version of my AsyncQueryRunner code after fixing numerous bugs I found while writing the unit tests. Add asynchronous batch, query, and update calls --- Key: DBUTILS-78 URL: https://issues.apache.org/jira/browse/DBUTILS-78 Project: Commons DbUtils Issue Type: New Feature Reporter: William R. Speirs Priority: Minor Fix For: 1.4 Attachments: AsyncQueryRunner.java, AsyncQueryRunnerTest.java I propose a new QueryRunner class, AsyncQueryRunner, which changes the return type of batch, query, and update methods. Instead of returning their respective return types, the methods would return a RunnableFuture. This would allow callers to either execute the RunnableFuture in a thread or via an CompletionService like the ExecutorCompletionService. I have attached a first cut at this class. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DBUTILS-79) fillStatement doesn't complain when there are too few parameters
[ https://issues.apache.org/jira/browse/DBUTILS-79?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13073198#comment-13073198 ] William R. Speirs commented on DBUTILS-79: -- See DBUTILS-78, it has an updated version of the fillStatement function which properly checks to see that the number of parameters passed in matches the number of parameters required by the statement. fillStatement doesn't complain when there are too few parameters Key: DBUTILS-79 URL: https://issues.apache.org/jira/browse/DBUTILS-79 Project: Commons DbUtils Issue Type: Bug Affects Versions: 1.3 Reporter: William R. Speirs Fix For: 1.4 Unless I'm reading the code incorrectly, it appears that the fillStatement function does not complain if you provide too few parameters. For example, if you supply an SQL statement like: select * from blah where ? = ?; but only provide a single parameter test, fillStatement returns without issue. However, only the first ? is actually set. Granted, this will almost always cause an exception to be thrown by the driver, but since there is already a check for too many parameters, why not check for too few as well? (FYI: I came across this bug, and a few others in my AsyncQueryRunner implementation, while re-writing the unit tests to use Mockito.) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DBUTILS-53) Set Derby up as a unit test database
[ https://issues.apache.org/jira/browse/DBUTILS-53?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13073203#comment-13073203 ] William R. Speirs commented on DBUTILS-53: -- See DBUTILS-78 for an updated unit test which covers 73% of the AsyncQueryRunner class. These unit tests should be easily adapted to cover QueryRunner. These unit tests also ensure that the ResultSet and PreparedStatement are always closed, and the Connection closed only when it is supposed to be. Set Derby up as a unit test database Key: DBUTILS-53 URL: https://issues.apache.org/jira/browse/DBUTILS-53 Project: Commons DbUtils Issue Type: Task Reporter: Henri Yandell Or hsqldb. I used Derby for Taglibs to test the sql tags and it worked well enough. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (DBUTILS-79) fillStatement doesn't complain when there are too few parameters
fillStatement doesn't complain when there are too few parameters Key: DBUTILS-79 URL: https://issues.apache.org/jira/browse/DBUTILS-79 Project: Commons DbUtils Issue Type: Bug Affects Versions: 1.3 Reporter: William R. Speirs Fix For: 1.4 Unless I'm reading the code incorrectly, it appears that the fillStatement function does not complain if you provide too few parameters. For example, if you supply an SQL statement like: select * from blah where ? = ?; but only provide a single parameter test, fillStatement returns without issue. However, only the first ? is actually set. Granted, this will almost always cause an exception to be thrown by the driver, but since there is already a check for too many parameters, why not check for too few as well? (FYI: I came across this bug, and a few others in my AsyncQueryRunner implementation, while re-writing the unit tests to use Mockito.) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (DBUTILS-78) Add asynchronous batch, query, and update calls
Add asynchronous batch, query, and update calls --- Key: DBUTILS-78 URL: https://issues.apache.org/jira/browse/DBUTILS-78 Project: Commons DbUtils Issue Type: New Feature Reporter: William R. Speirs Priority: Minor Fix For: 1.4 Attachments: AsyncQueryRunner.java I propose a new QueryRunner class, AsyncQueryRunner, which changes the return type of batch, query, and update methods. Instead of returning their respective return types, the methods would return a RunnableFuture. This would allow callers to either execute the RunnableFuture in a thread or via an CompletionService like the ExecutorCompletionService. I have attached a first cut at this class. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DBUTILS-78) Add asynchronous batch, query, and update calls
[ https://issues.apache.org/jira/browse/DBUTILS-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William R. Speirs updated DBUTILS-78: - Attachment: AsyncQueryRunner.java Add asynchronous batch, query, and update calls --- Key: DBUTILS-78 URL: https://issues.apache.org/jira/browse/DBUTILS-78 Project: Commons DbUtils Issue Type: New Feature Reporter: William R. Speirs Priority: Minor Fix For: 1.4 Attachments: AsyncQueryRunner.java I propose a new QueryRunner class, AsyncQueryRunner, which changes the return type of batch, query, and update methods. Instead of returning their respective return types, the methods would return a RunnableFuture. This would allow callers to either execute the RunnableFuture in a thread or via an CompletionService like the ExecutorCompletionService. I have attached a first cut at this class. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DBUTILS-53) Set Derby up as a unit test database
[ https://issues.apache.org/jira/browse/DBUTILS-53?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13072641#comment-13072641 ] William R. Speirs commented on DBUTILS-53: -- I've noticed that the unit tests currently don't leverage JUnit 4 or mocking frameworks like Mockito. These unit tests also don't cover the batch, query, or update methods. As a large part of the purpose of this library is to ensure all resources are properly closed, it would make sense to ensure this is being done via the unit tests. I guess what I'm proposing is to use Mockito to mock Connection, PreparedStatement, and ResultSet and then ensure that the close() methods are called on each. Thoughts? Set Derby up as a unit test database Key: DBUTILS-53 URL: https://issues.apache.org/jira/browse/DBUTILS-53 Project: Commons DbUtils Issue Type: Task Reporter: Henri Yandell Or hsqldb. I used Derby for Taglibs to test the sql tags and it worked well enough. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
