commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ronald Dauster <...@ronald-dauster.de>
Subject Re: [DBUtils] SQL Server null - Not implemented (type is java.sql.Types.OTHER)
Date Tue, 06 Jul 2004 08:15:39 GMT
Unfortunately, this solution has the same problems as David's proposed 
setNullType
method:  You are adding a property to QueryRunner that really belongs to 
the Connection
or DataSource.

Since QueryRunner can be used concurrently with connections to different
databases, it is perfectly legal to do

    QueryRunner runner = new QueryRunner()
    Thread A: runner.update(myOracleConnection, ...)
    Thread B: runner.update(mySQLServerConnection, ...)

Combine this with your proposed setFillerStatement method and you have

    QueryRunner runner = new QueryRunner()
    Thread A: runner.setFillerStatement(myOracleFiller)
    Thread B: runner.setFillerStatement(mySQLServerFiller)
    Thread A: runner.update(myOracleConnection, ...) 
    ==> SQLException

Therefore, you would have to add another method for each existing
method that takes a connection argument as well as a params argument.
(4 methods in 1.0,  5 in 1.1, e. g.):

    int[] batch(String, Object[][], FillerStatement)

Assume you have done this.  What about the original methods?
They can't use the FillerStatement set with setFillerStatement
but ignoring it will be at least confusing.

Ronald

>Hello:
>
>I have a suggestion. We could create a interface called 
>FillerStatement. This would have a only method: void 
>fillStatement(PreparedStatement stmt, Object[] params). The 
>basic implementation of this interface will work like 
>fillStatement() now in QueryRunner. Like this:
>
>
>public class BasicFillerStatement implements FillerStatement {
>
>   public void fillStatement(PreparedStatement stmt, Object[] 
>params) {
>        if (params == null) {
>            return;
>        }
>
>        for (int i = 0; i < params.length; i++) {
>            if (params[i] != null) {
>                stmt.setObject(i + 1, params[i]);
>            } else {
>                stmt.setNull(i + 1, Types.OTHER);
>            }
>        }
>   }
>
>}
>
>We would have a SQLServerFillerStatement with solution that I 
>used:
>
>public class SQLServerFillerStatement implements 
>FillerStatement {
>
>   public void fillStatement(PreparedStatement stmt, Object[] 
>params) {
>        if (params == null) {
>            return;
>        }
>
>        for (int i = 0; i < params.length; i++) {
>           stmt.setObject(i + 1, params[i]);
>        }
>   }
>
>}
>
>
>And we would have a OracleFillerStatement, 
>MySQLFillerStatement, FirebirdFillerStatement, and so on. In 
>this form we could be a "personalized" way to attend any kind 
>of database (or JDBC driver) features, mainly with null 
>parameters.
>How do we use it? In QueryRunner implementation we would had 
>a attribute for FillerStatement. By default this attribute 
>will implement BasicFillerStatement:
>
>   private FillerStatement fillerStatement = new 
>BasicFillerStatement();
>
>And we would have a setFillerStatement() method:
>
>   public void setFillerStatement(FillerStatement filler) {
>      this.fillerStatement = filler;
>   }
>
>In update(), query() and batch() methods, it will call 
>fillStatement() method from fillerStatement attribute:
>
>   this.fillerStatement.fillStatement(stmt, params);
>   
>So, if I am using a SQLServer like database, We could do this:
>
>   QueryRunner runner = new QueryRunner();
>   runner.setFillerStatement(new SQLServerFillerStatement());
>
>Well, what do you think?
>
>Thanks,
>
>Rafael Ubiratam Clemente Afonso
>r.u.c.afonso@uol.com.br
>---------------------------------
>Where is Debug?
>Debug is on the Table!
>
>  
>


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org


Mime
View raw message