[jira] Commented: (IBATIS-226) Support Commons DBUtils ResultSetHandler
[
http://issues.apache.org/jira/browse/IBATIS-226?page=comments#action_12422685 ]
Fabio Insaccanebbia commented on IBATIS-226:
Has anybody tried to implement this RFE?
I've tried and I have an implementation but I feel it's a bit naive (I don't
have enough experience of the inner workings of iBatis)
Do you expect to create a DefaultResultSetHandler that encapsulates all the
logic iBatis has to transform a ResultSet into an Object of some sort?
Or do you think the ResultSetHandler is just something alternative to the
normal logic?
Something like:
if (rsh != null) {
result= rsh.handle(rs);
} else {
// ...normal logic here..
}
The second way (the one I tried to develop) has as a consequence that there is
no way to use ibatis paging or caching when using the ResultSetHandler; is
this acceptable?
Support Commons DBUtils ResultSetHandler
Key: IBATIS-226
URL: http://issues.apache.org/jira/browse/IBATIS-226
Project: iBatis for Java
Issue Type: New Feature
Components: SQL Maps
Reporter: Paul Benedict
Sometimes I need total control over the caching mechanism for very critical
systems. I need to also guarantee object identity and I can only do this when
handling the result set myself. I propose adding an attribute to the
statement tag (and also select, insert, update) that will specify a
subclass of ResultSetHandler so that I may write custom code and decode the
ResultSet myself. The ResultSetHandler class is part of the Jakarta Commons
DBUtils package. It is extremely useful!
select id=findMyObject resultSetHandler=com.company.MyResultSetHandler
To prevent excess object creation, IBATIS must reuse the same instance it
creates.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (IBATIS-226) Support Commons DBUtils ResultSetHandler
[
http://issues.apache.org/jira/browse/IBATIS-226?page=comments#action_12359001 ]
Paul Benedict commented on IBATIS-226:
--
I haved talked with Larry privately about these ideas and now I am taking them
public for review.
I think we can provide callback hooks into iBATIS at the DAO level. So we would
have new overloaded methods like:
queryForList(name, params, callback);
Where callback can implement one to many interfaces:
public interface ResultSetHandler {
public Object handle(ResultSet);
}
public interface StatementHandler {
public boolean preProcess(StatementContext cxt);
public boolean postProcess(StatementContext cxt);
}
I have broken up these 3 methods into 2 interfaces so iBATIS doesn't have to
perform callbacks on operations that are not requested by the developer. iBATIS
will inspect the callback interfaces to see what is supported and invoke them
if they are present.
The ResultSetHandler (could be from the DbUtils package) allows programatic
access to build the returning object. Useful for advanced situations (and can
be used to override any resultMap present).
The StatementHandler I propose takes usage of the commons-chain package. This
will allow people to build processing chains before and after the statement
executes. Why chain? If you give people the option to do processing, eventually
someone will build a chain so we might as well support it out-of-the-box and
tout our features. :-) Also the StatementContext object would contain metadata
about the current statement invocation and expose objects such as the
MappedStatement, parameters passed in, even the built SQL. Some of these
properties will be read-write so that people can modify the generated SQL
before it gets executed. Larry suggested this would be a good way to use iBATIS
to generate dynamic HQL and then turn it into SQL.
OK. Let's hear it!
Support Commons DBUtils ResultSetHandler
Key: IBATIS-226
URL: http://issues.apache.org/jira/browse/IBATIS-226
Project: iBatis for Java
Type: New Feature
Components: SQL Maps
Reporter: Paul Benedict
Sometimes I need total control over the caching mechanism for very critical
systems. I need to also guarantee object identity and I can only do this when
handling the result set myself. I propose adding an attribute to the
statement tag (and also select, insert, update) that will specify a
subclass of ResultSetHandler so that I may write custom code and decode the
ResultSet myself. The ResultSetHandler class is part of the Jakarta Commons
DBUtils package. It is extremely useful!
select id=findMyObject resultSetHandler=com.company.MyResultSetHandler
To prevent excess object creation, IBATIS must reuse the same instance it
creates.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (IBATIS-226) Support Commons DBUtils ResultSetHandler
[ http://issues.apache.org/jira/browse/IBATIS-226?page=comments#action_12358103 ] Clinton Begin commented on IBATIS-226: -- Random thoughts... Sometimes I need total control over the caching mechanism for very critical systems. I need to also guarantee object identity and I can only do this when handling the result set myself. Fair enough, but if you just turn iBATIS cache models off, then you can easily build a caching mechanism above the iBATIS API that will guarantee object identity etc. You can also use a RowHandler that will give you basically what you're looking for, but without having to deal with the result set. I don't believe that you MUST have acces to the result set to achieve object identity (unless you're tightly binding your object model to your data model, in which case I suppose you should use an ORM). That said, I don't have a problem with making this an alternative approach to handling result sets, to override the normal handling. In fact, I prefer it to other proposed alternatives of returning ResultSets or RowSets There is a lot of potential to mess things up by overriding such a thing in iBATISbut I suppose we don't need to support it beyond the interface. As for the dependency on DBUtils...yeah, that's definitely out of the question (especially for 3 lines of code). However, it is a simple interface that we could easily include in iBATIS. Cheers, Clinton Support Commons DBUtils ResultSetHandler Key: IBATIS-226 URL: http://issues.apache.org/jira/browse/IBATIS-226 Project: iBatis for Java Type: New Feature Components: SQL Maps Reporter: Paul Benedict Sometimes I need total control over the caching mechanism for very critical systems. I need to also guarantee object identity and I can only do this when handling the result set myself. I propose adding an attribute to the statement tag (and also select, insert, update) that will specify a subclass of ResultSetHandler so that I may write custom code and decode the ResultSet myself. The ResultSetHandler class is part of the Jakarta Commons DBUtils package. It is extremely useful! select id=findMyObject resultSetHandler=com.company.MyResultSetHandler To prevent excess object creation, IBATIS must reuse the same instance it creates. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (IBATIS-226) Support Commons DBUtils ResultSetHandler
[ http://issues.apache.org/jira/browse/IBATIS-226?page=comments#action_12358110 ] Paul Benedict commented on IBATIS-226: -- My idea was also spawned by the author of Jakarta Tapestry, Howard Lewis Ship. See his blog entry about performance using reflection compared to direct object navigation: http://howardlewisship.com/blog/2005/11/improving-tapestry-performance.html I am optimizing performance in this one subsystem and it looks like I can get very good gains by hard-coding the retrival of the result set. Reflection is slower (and that's not too much of a concern for general purposes), but for a few exception cases I want the fastest performance. So I appreciate hearing Clinton saying he prefer[s] it to other proposed alternatives. This is obviously not an everydays concern, but it's always nice to support power users too. My philosophy is to have general support, but provide pluggable interfaces for advanced designs. Support Commons DBUtils ResultSetHandler Key: IBATIS-226 URL: http://issues.apache.org/jira/browse/IBATIS-226 Project: iBatis for Java Type: New Feature Components: SQL Maps Reporter: Paul Benedict Sometimes I need total control over the caching mechanism for very critical systems. I need to also guarantee object identity and I can only do this when handling the result set myself. I propose adding an attribute to the statement tag (and also select, insert, update) that will specify a subclass of ResultSetHandler so that I may write custom code and decode the ResultSet myself. The ResultSetHandler class is part of the Jakarta Commons DBUtils package. It is extremely useful! select id=findMyObject resultSetHandler=com.company.MyResultSetHandler To prevent excess object creation, IBATIS must reuse the same instance it creates. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
