setString vs setNString / getString vs getNString about sql2o HOT 8 CLOSED

I think we need to add two abstractions RowHandler and ColumnHandler. They would work like this:

ResultSetHandler#process(ResultSet) loops over each row:

call RowHandler#process(ResultSet)

RowHandler#process(ResultSet) loops over each column:

call ColumnHandler#process(ResultSet, int)
call Converter#convert(Object)
call Setter#setProperty(Object, Object)

This would need to be fleshed out a bit, but would mean we have 5 overall components:

ResultSetHandler -> RowHandler -> ColumnHandler -> Converter -> Setter

If we supply standard implementations for those, and allow users to plug in to any stage, that should cover everything. The stuff you are asking about would be a custom ColumnHandler. But we might even be able to handle it in the default handler, because it could try to call the appropriate ResultSet#get method based on the property type, and fall back to ResultSet#getObject.

Thoughts?

from sql2o.

So you propose to rename ResultSetHandler to RowHandler?
As for converter I'm not shure it's a requred part of ColumnHandler. ColumnHandler can call directrly Resultset.getInt for example to avoid unnecessary boxing and unboxing

from sql2o.

talking about http://commons.apache.org/proper/commons-dbutils/apidocs/org/apache/commons/dbutils/RowProcessor.html - it's not a good abstraction api example.
plain different ResultSetHandler's can cover all of it:

ResultSetHandler<Map<String,Object>>
ResultSetHandler<Object[]>
ResultSetHandler<MyBean>

ResultSetHandler must process one ResultSetRow per-call
You can reuse ResultSetHandler for

1. iterating over resultset to convert it anything you want (get rid of other IteratingresultSetImplementations)
2. create collection from resultSet
3. obtain first line from resultSet

from sql2o.

btw. you can feed sql2o ResultSetHandler to ApacheDbUtils (via simplest adapter)
you can reuse ApacheDbUtils handlers into sql2o (same way via simplest adapter)

maybe just reuse ApacheDbUtils ResultSetHandler as-is (to avoid dependency we can create same interface in sql2o project but in same package)

from sql2o.

Ah I didn't realize what ResultSetHandler was doing, sorry. I thought it was handling the entire ResultSet but it's just handling one row, and the ResultSetIterator is handling the entire ResultSet. That seems good to me.

Yes you are right about the Converter, so I think the overall picture should be:

ResultSetIterator -> ResultSetHandler -> ColumnHandler -> Setter

However in this case, ColumnHandler would be very similar to the current Converter, but would allow more flexibility. Instead of:

public interface Converter<T> {
    T convert(Object val) throws ConverterException;
}

It would be:

public interface ColumnHandler<T> {
    T process(ResultSet rs, int colIdx) throws ConverterException;
}

The IntegerColumnHandler could just call rs.getInt, and the DateTimeColumnHandler (joda) could call rs.getObject and then construct a DateTime, etc.

Users could register a ColumnHandler for different property types, just like they currently register Converters. Also this would be a completely breaking change, so it would have to be a 2.0 release.

from sql2o.

Actually for backwards compatibility, we could keep the existing Converter interface, and have a DefaultColumnHandler that calls rs.getObject and then uses a converter if one exists

from sql2o.

the question is: does we really need backwards compatibility?

2014-04-07 19:10 GMT+04:00 Alden Quimby [email protected]:

Actually for backwards compatibility, we could keep the existing Converterinterface, and have a
DefaultColumnHandler that calls rs.getObject and then uses a converter if
one exists

Reply to this email directly or view it on GitHubhttps://github.com//issues/77#issuecomment-39742426
.

from sql2o.

@aaberg would have to make that call, but I would say we should shoot for
backwards compatibility for one version and mark things deprecated. Then
remove deprecated things in a following release.

Maybe not though if it's a 2.0 release and we add good documentation on how
to upgrade

On Monday, April 7, 2014, dimzon [email protected] wrote:

the question is: does we really need backwards compatibility?

2014-04-07 19:10 GMT+04:00 Alden Quimby <[email protected]javascript:_e(%7B%7D,'cvml','[email protected]');

:

Actually for backwards compatibility, we could keep the existing
Converterinterface, and have a
DefaultColumnHandler that calls rs.getObject and then uses a converter if
one exists

Reply to this email directly or view it on GitHub<
https://github.com/aaberg/sql2o/issues/77#issuecomment-39742426>
.

Reply to this email directly or view it on GitHubhttps://github.com//issues/77#issuecomment-39757924
.

from sql2o.