You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ibatis.apache.org by "Paul Benedict (JIRA)" <ib...@incubator.apache.org> on 2005/11/20 07:29:25 UTC
[jira] Created: (IBATIS-226) Support Commons DBUtils ResultSetHandler
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
Posted by "Jeff Butler (JIRA)" <ib...@incubator.apache.org>.
[ http://issues.apache.org/jira/browse/IBATIS-226?page=comments#action_12358088 ]
Jeff Butler commented on IBATIS-226:
------------------------------------
Paul, it seems that you have caching requirements that are really beyond the capabilities (current or imagined) of iBATIS. It's best to think of iBATIS as caching result sets - not "objects" in the sense that you need them. This is a fundamental difference between what iBATIS does, and what you seem to need it to do.
I would seriously suggest that you investigate some other object caching solution that is more appropriate for your particular problem space. I doubt that iBATIS will ever get where you want it to be, it's simply not designed for that purpose. You could still use iBATIS for data access, but check your own cache first before calling iBATIS.
Alternatively, dare I say it, would Hibernate be a better fit for your system? They've spent a lot of time (and lots of code) trying to understand object identity and caching. As far as I know, we don't ever plan to deal with object identity in iBATIS.
BTW - I would make this same comment for IBATIS-222.
> 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
Posted by "Paul Benedict (JIRA)" <ib...@incubator.apache.org>.
[ http://issues.apache.org/jira/browse/IBATIS-226?page=comments#action_12359002 ]
Paul Benedict commented on IBATIS-226:
--------------------------------------
Chaining also allows people to insert their own utility tasks such as white-space trimming (http://issues.apache.org/jira/browse/IBATIS-143). So this really opens up an array of possibilities. We could even write some of these common tasks so people could just optionally plug them in.
> 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
Posted by "Paul Benedict (JIRA)" <ib...@incubator.apache.org>.
[ http://issues.apache.org/jira/browse/IBATIS-226?page=comments#action_12358098 ]
Paul Benedict commented on IBATIS-226:
--------------------------------------
Jeff and Larry, thank you for your kind replies.
First, remember that Java is completely dynamically linked. Just because you include support for DBUtils, does not mean you then have to include that jar in your distribution -- it's ONLY if you actually end up using that file. Spring is totally packaged this way; if you don't use a certain aspect, you also don't need the supporting libraries because they are never invoked. DBUtils is such a small library; I understand the concern BUT have you seen the class? It is LITERALLY this:
public interface ResultSetHandler {
public Object handle(ResultSet rs);
}
http://svn.apache.org/viewcvs.cgi/jakarta/commons/proper/dbutils/trunk/src/java/org/apache/commons/dbutils/ResultSetHandler.java?rev=155411&view=markup
However, if you're looking to completely avoid dependency on another library, you can easily include this class in the distribution yourself. For instance, in the Commons BeanUtils package they actually import a few classes from Commons Lang to prevent the dependency on the entire library. This is a very smart option. Likewise, linking in this ONE file gives a great benefit to all IBATIS.
As for Jeff's comment: I use Hibernate all day at work and I probably would not use it otherwise. It's a great product, but personally I have pre-written queries in XML files and IBATIS is a natural migration path for me. I have large SQL statements that would be a real burden (or impossible) to turn into HQL. Besides, replacing my ? with the #var# and using <sql> replacements, IBATIS gives me so much benefit that I didn't have before. I love IBATIS but I am also stretching it to the max....
I take my problems to the OS community because my problems are opportunties for product improvements. I really find this feature valuable and a PLUS for IBATIS, but please give me a hard thought on this issue. Let me submit a patch and you guys can then debate the merit of it looking at the code. It might be as good as I say and not as terrible as you think.
> 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
Posted by "Clinton Begin (JIRA)" <ib...@incubator.apache.org>.
[ 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 iBATIS....but 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
Posted by "Paul Benedict (JIRA)" <ib...@incubator.apache.org>.
[ 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
[jira] Commented: (IBATIS-226) Support Commons DBUtils ResultSetHandler
Posted by "Larry Meadors (JIRA)" <ib...@incubator.apache.org>.
[ http://issues.apache.org/jira/browse/IBATIS-226?page=comments#action_12358082 ]
Larry Meadors commented on IBATIS-226:
--------------------------------------
I do not see any reason to add a dependency on DBUtils. Nothing against DBUtils, just that we are very opposed to adding unneeded dependencies into iBATIS because of the management nightmare they become (i.e., what version do we support / require?).
However, I do agree that we do need to support a more event-driven extensibility model in version 3.x of iBATIS.
> 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
Posted by "Paul Benedict (JIRA)" <ib...@incubator.apache.org>.
[ 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