> getMoreResults() precedes getResultSet().
>
> Using this is slightly more efficient than an update followed by a query.
JDBC documentation says I must to call getMoreResults() after
getResultSet().
I have no way to test this stuff, doe's some opensource RDMS driver supports
getResultSet() after update and
something like this ?
INSERT INTO tbl (id) VALUES (
(
CASE WHEN ( SELECT MAX(id) FROM tbl ) is NULL
THEN 0
ELSE (SELECT MAX(id) FROM tbl )
END
) + 1
) ;
SELECT MAX(id) FROM tbl;
>
> Another thing I wanted to mention is that it seems you should have two
visible interfaces to users, one for how to act on a result set and another
for retrieving objects from the result set.
>
> In my wrapper, I defined:
>
> public interface Retriever
> {
> public Object retrieve(ResultSet rs)
> throws SQLException;
> }
>
>
> I use this in a single-result handler, like this:
>
> Retriever rtr;
>
> public Object handle(ResultSet rs) throws SQLException
> {
> if(rs.next()){
> return rtr.retrieve(rs);
> }
> throw new SQLException(....
> }
>
> I also use this in collection handler like this:
>
> Retriever rtr;
>
> final public Object handle(ResultSet rs) throws SQLException
> {
> while(rs.next()){
> cln.add(rtr.retrieve(rs));
> }
> return cln;
> }
>
> This way, I reuse my implementation of Retriever for both queries
retrieving single and multiple sets.
>
> Only issue for me has been that it has same signature as ResultSetHandler,
so I couldn't have my collection handler implementing Retriever because of
ambiguity in my usage.
I think it must be possible to solve using adapters.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
|