ibatis-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <russ.jack...@accenture.com>
Subject RE: DB portability for iBatis 3 Mappers
Date Tue, 22 Sep 2009 17:33:18 GMT
OK.  Thanks Clinton.  If I have any trouble doing so I will send you a note.  Thanks.

Russ

________________________________
From: Clinton Begin [mailto:clinton.begin@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.jackson@accenture.com<mailto:russ.jackson@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.jackson@accenture.com<mailto:russ.jackson@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-unsubscribe@ibatis.apache.org<mailto:dev-unsubscribe@ibatis.apache.org>
For additional commands, e-mail: dev-help@ibatis.apache.org<mailto:dev-help@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.

Mime
View raw message