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> 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 > > > > 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 > For additional commands, e-mail: dev-h...@ibatis.apache.org >
