Re: [DbUtils] Could AsyncQueryRunner be a wrapper around a QueryRunner?
On Wed, Feb 8, 2012 at 5:04 AM, William Speirs wrote:
> This is not a bad idea, but I would need to give it more thought.
>
> I tried to reduce code dup when I created AsyncQueryRunner by creating
> AbstractQueryRunner[1], could we just add more code to that class?
>
I was thinking of having the AsyncQueryWrapper decorate the QueryRunner
with async behaviour, in the same way a BufferedInputStream might decorate
an InputStream.
Here's a patch that shows what I mean. It causes all the interaction-based
tests to fail, but I just wanted to get your take on whether this was a
good/feasible idea.
Moandji
Index: src/main/java/org/apache/commons/dbutils/AsyncQueryRunner.java
===
--- src/main/java/org/apache/commons/dbutils/AsyncQueryRunner.java
(revision 1238942)
+++ src/main/java/org/apache/commons/dbutils/AsyncQueryRunner.java
(working copy)
@@ -17,8 +17,6 @@
package org.apache.commons.dbutils;
import java.sql.Connection;
-import java.sql.PreparedStatement;
-import java.sql.ResultSet;
import java.sql.SQLException;
import java.util.concurrent.Callable;
import java.util.concurrent.ExecutorService;
@@ -36,6 +34,12 @@
public class AsyncQueryRunner extends AbstractQueryRunner {
private final ExecutorService executorService;
+private final QueryRunner queryRunner;
+
+public AsyncQueryRunner(ExecutorService executorService, QueryRunner
queryRunner) {
+ this.executorService = executorService;
+ this.queryRunner = queryRunner;
+}
/**
* Constructor for AsyncQueryRunner.
@@ -85,59 +89,7 @@
public AsyncQueryRunner(DataSource ds, boolean pmdKnownBroken,
ExecutorService executorService) {
super(ds, pmdKnownBroken);
this.executorService = executorService;
-}
-
-/**
- * Class that encapsulates the continuation for batch calls.
- */
-protected class BatchCallableStatement implements Callable {
-private final String sql;
-private final Object[][] params;
-private final Connection conn;
-private final boolean closeConn;
-private final PreparedStatement ps;
-
-/**
- * Creates a new BatchCallableStatement instance.
- *
- * @param sql The SQL statement to execute.
- * @param params An array of query replacement parameters. Each row in
- *this array is one set of batch replacement values.
- * @param conn The connection to use for the batch call.
- * @param closeConn True if the connection should be closed, false
otherwise.
- * @param ps The {@link PreparedStatement} to be executed.
- */
-public BatchCallableStatement(String sql, Object[][] params,
Connection conn, boolean closeConn, PreparedStatement ps) {
-this.sql = sql;
-this.params = params;
-this.conn = conn;
-this.closeConn = closeConn;
-this.ps = ps;
-}
-
-/**
- * The actual call to executeBatch.
- *
- * @return an array of update counts containing one element for each
command in the batch.
- * @throws SQLException if a database access error occurs or one of
the commands sent to the database fails.
- * @see PreparedStatement#executeBatch()
- */
-public int[] call() throws SQLException {
-int[] ret = null;
-
-try {
-ret = ps.executeBatch();
-} catch (SQLException e) {
-rethrow(e, sql, (Object[])params);
-} finally {
-close(ps);
-if (closeConn) {
-close(conn);
-}
-}
-
-return ret;
-}
+this.queryRunner = new QueryRunner(ds, pmdKnownBroken);
}
/**
@@ -183,109 +135,13 @@
* @return A Callable which returns the number of rows
updated per statement.
* @throws SQLException If there are database or parameter errors.
*/
-private Callable batch(Connection conn, boolean closeConn, String
sql, Object[][] params) throws SQLException {
-if (conn == null) {
-throw new SQLException("Null connection");
-}
-
-if (sql == null) {
-if (closeConn) {
-close(conn);
-}
-throw new SQLException("Null SQL statement");
-}
-
-if (params == null) {
-if (closeConn) {
-close(conn);
-}
-throw new SQLException("Null parameters. If parameters aren't
need, pass an empty array.");
-}
-
-PreparedStatement stmt = null;
-Callable ret = null;
-try {
-stmt = this.prepareStatement(conn, sql);
-
-for (int i = 0; i < params.length; i++) {
-this.fillStatement(stmt, params[i]);
-stmt.addBatch();
-}
-
-
Re: [DbUtils] Returning the newly-generated primary key after an insert
Hi Simone, On Wed, Feb 1, 2012 at 9:24 AM, Simone Tripodi wrote: > I had a quick look at the patch and IMHO it looks good. I assigned the > issue to Bill who's more deep inside DbUtils than me :) > > All the best and thanks for contributing! > Thanks! I should be able to make some time to make any necessary changes, like adding JavaDoc, a few more unit tests, etc. Moandji
Re: [DbUtils] Returning the newly-generated primary key after an insert
On Sun, Jan 29, 2012 at 6:21 PM, William Speirs wrote: > Interesting... would you be willing to donate your QueryRunner > implementation? If so, open a JIRA ticket[1] with your request for this > functionality, and upload your code. > Done, with embryonic patch: https://issues.apache.org/jira/browse/DBUTILS-87 Moandji
Re: [DbUtils] Returning the newly-generated primary key after an insert
I don't mind, but it's a very limited implementation. I don't know if it's abywhere near general-purpose for your needs. I'll post it and let you decide. Moandji On 29 Jan 2012 18:21, "William Speirs" wrote: > Interesting... would you be willing to donate your QueryRunner > implementation? If so, open a JIRA ticket[1] with your request for this > functionality, and upload your code. > > Thanks... > > Bill- > > [1] https://issues.apache.org/jira/browse/DBUTILS > > On Sun, Jan 29, 2012 at 11:19 AM, Moandji Ezana wrote: > > > On Sun, Jan 29, 2012 at 6:05 PM, William Speirs > > wrote: > > > > > That is a question more specific to the database you're using, than > > > DBUtils. For some databases this means writing a stored procedure which > > > performs the insert, and then a special select to get the primary key. > > You > > > can of course use DBUtils to call this stored proc and read the primary > > > key. > > > > > > As Simone mentioned, I'd like to use Statement#getGeneratedKeys(), which > > requires passing Statement.RETURN_GENERATED_KEYS to > > Connection#prepareStatement(). It doesn't seem possible to do this with > the > > current API. > > > > I've written my own QueryRunner for the time being, but it seems like a > > common enough requirement to be in the library itself. > > > > Moandji > > >
Re: [DbUtils] Returning the newly-generated primary key after an insert
On Sun, Jan 29, 2012 at 6:05 PM, William Speirs wrote: > That is a question more specific to the database you're using, than > DBUtils. For some databases this means writing a stored procedure which > performs the insert, and then a special select to get the primary key. You > can of course use DBUtils to call this stored proc and read the primary > key. As Simone mentioned, I'd like to use Statement#getGeneratedKeys(), which requires passing Statement.RETURN_GENERATED_KEYS to Connection#prepareStatement(). It doesn't seem possible to do this with the current API. I've written my own QueryRunner for the time being, but it seems like a common enough requirement to be in the library itself. Moandji
[DbUtils] Returning the newly-generated primary key after an insert
Is it possible with the current API to do an insert and get back the generated primary key, rather than the number of affected rows? Best regards, Moandji
Re: [dbutils] Mapping from JPA annotations
Interesting. I've never used MyBatis, but U've read the docs and it didn't really seem to help write less SQL. Do you all only use DbUtils for smaller projects, then? Moandji On 19 Jan 2012 22:32, "Simone Tripodi" wrote: > I personally use MyBatis[1] - which is DbUtils with superpowers > > -Simo > > [1] http://www.mybatis.org > > http://people.apache.org/~simonetripodi/ > http://simonetripodi.livejournal.com/ > http://twitter.com/simonetripodi > http://www.99soft.org/ > > > > On Thu, Jan 19, 2012 at 9:28 PM, Moandji Ezana wrote: > > On 19 Jan 2012 20:26, "Gary Gregory" wrote: > >> > >> So why not use Hibernate or any JPA provider? > >> > >> Gary > > > > Plenty of reasons, such as the library's simplicity and the control it > > affords. And I don't want the lazy-loading, 1st-level cache, etc. it > > provides. > > > > However, there are 2 big missing pieces: reducing the amount of > duplication > > in SQL (which makes refactoring the code or the DB difficult) and mapping > > joins. > > > > Arguably, SQL generation is out of scope. Joins, however, shouldn't be. I > > think JPA annotations > > > > Out of curiosity, how do you guys manage the SQL strings and the joins in > > your projects? > > > > Moandji > > - > To unsubscribe, e-mail: user-unsubscr...@commons.apache.org > For additional commands, e-mail: user-h...@commons.apache.org > >
Re: [dbutils] Mapping from JPA annotations
On 19 Jan 2012 20:26, "Gary Gregory" wrote: > > So why not use Hibernate or any JPA provider? > > Gary Plenty of reasons, such as the library's simplicity and the control it affords. And I don't want the lazy-loading, 1st-level cache, etc. it provides. However, there are 2 big missing pieces: reducing the amount of duplication in SQL (which makes refactoring the code or the DB difficult) and mapping joins. Arguably, SQL generation is out of scope. Joins, however, shouldn't be. I think JPA annotations Out of curiosity, how do you guys manage the SQL strings and the joins in your projects? Moandji
Re: [dbutils] Mapping from JPA annotations
On Thu, Jan 19, 2012 at 3:52 PM, William Speirs wrote: > No, JPA hasn't been added to DbUtils in any way. I'm not familiar with JPA, > could you give an example of what you'd like to see in DbUtils? > I don't want it in DbUtils, it can be built purely as a 3rd party extension. I was just wondering if someone knew of an existing extension so I don't have to do it myself. As part of a partial implementation I've done, I found that creating a JPA-aware BeanProcessor was enough to provide JPA support for ResultSet => Object. I also hope that this would be a good way to support joins, which, I believe, DbUtils does not do. My general goal is to automate a bit more than DbUtils does (e.g. by generating basic queries from annotations and having mapping information that's more flexible than just getters/setters), while still being able to drop down to DbUtils's very nice lower-level functionalities. Moandji
Re: [dbutils] Mapping from JPA annotations
Hello, Has anyone extended DbUtils to use JPA annotations? I've partially written a BeanProcessor that does so, but thought it might already exist. I did so in the context of wanting DbUtils's simplicity, but without having to write quite as much boilerplate SQL. Also, this could lead to a nice way to handle joins, which, as far as I am aware, are not currently supported in DbUtils. Best regards, Moandji
