OK. Thanks Clinton. If I have any trouble doing so I will send you a note. Thanks.
Russ ________________________________ From: Clinton Begin [mailto:clinton.be...@gmail.com] Sent: Tuesday, September 22, 2009 12:31 PM To: dev@ibatis.apache.org Subject: Re: DB portability for iBatis 3 Mappers Best thing to do for this is create a Jira feature request ticket. Clinton On Tue, Sep 22, 2009 at 10:34 AM, <russ.jack...@accenture.com<mailto:russ.jack...@accenture.com>> wrote: Hey iBatis team, The feature in iBatis 3 to use getMapper() to obtain a dynamic implementation of the DAO interface is extremely cool. However, there is one serious shortcoming - mapped statement implementations that are DB product specific/variant are not currently supported by this. For example, say I have a couple of vendor-specific SELECT statements that represent the same query. The way one can address this situation is described in the following blog posting by Jeff Hair (who happens to be a colleague of mine): http://jshair.blogspot.com/ (scroll down to the iBatis entry) As you can see, Jeff describes adding a base DAO class that extends Spring's SqlMapClientDaoSupport. Inside this base class the checkMappedStatement() method manipulates the statement name to be DB product specific (based on the db metadata obtained from the db connection) and attempts to look up a mapped statement based on that name. If that fails, the original/default name is used to find the mapped statement. What I have done is basically push a variant of the implementation that Jeff describes down into your DefaultSqlSession class to provide the capability for your dynamic mapper methods to execute overloaded, vendor-specific SQL statements - all transparent to the DAO client. (see attached - I put the new work just after your constructor) I built the iBatis project locally and deployed it to my environment and it seems to work fine. There is one kink that still needs to be worked out - I did not put this mapped SQL overload into your MapperMethod.determineCommandType() method and as a result, the xml mapper still requires that a non-db-specific SELECT statement exists. For example, consider the following: For argument's sake I have getAll-Oracle and getAll-HSQL mapped SELECT statements representing some SELECT statements that are, for one reason or another, vendor-specific. But, I also have to provide an undesired getAll implementation to prevent an exception in the determineCommandType() method. <mapper namespace="com.acme.banking.persistence.dao.ITransactionTypeDao"> <resultMap id="get-transactionType-result" type="TransactionType"> <result property="code" column="code"/> <result property="title" column="title"/> </resultMap> <select id="getAll-HSQL" resultType="TransactionType"> SELECT code, title FROM transaction_type </select> <select id="getAll-Oracle" resultType="TransactionType"> SELECT title, code FROM transaction_type </select> <select id="getAll" resultType="TransactionType"> SELECT title, code FROM transaction_type </select> </mapper> It would be great if you could eliminate this problem/requirement if you decide to use this implementation/idea. Also, this evening was the first time I've looked at your source code and I didn't spend a lot of time with it so I just wedged this solution in where it would work - it may not fit with your overall design/architecture and I'm sure it will have to be refactored. Thanks and keep up the great work. Please let me know if I can clarify anything or be of further assistance. I do hope to provide some feedback on your iBatis 3 user guide in the not too distant future. Thanks again. Russ Jackson Accenture Sr. Consultant 407 S. Pennsylvania Ave, Suite 201 Joplin, MO 64801 (417) 626-6524 russ.jack...@accenture.com<mailto:russ.jack...@accenture.com> This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@ibatis.apache.org<mailto:dev-unsubscr...@ibatis.apache.org> For additional commands, e-mail: dev-h...@ibatis.apache.org<mailto:dev-h...@ibatis.apache.org> This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited.
