You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ibatis.apache.org by ru...@accenture.com on 2009/09/22 18:34:04 UTC
DB portability for iBatis 3 Mappers
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<ma...@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.
RE: DB portability for iBatis 3 Mappers
Posted by ru...@accenture.com.
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, <ru...@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<ma...@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<ma...@ibatis.apache.org>
For additional commands, e-mail: dev-help@ibatis.apache.org<ma...@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.
Re: DB portability for iBatis 3 Mappers
Posted by Clinton Begin <cl...@gmail.com>.
Best thing to do for this is create a Jira feature request ticket.
Clinton
On Tue, Sep 22, 2009 at 10:34 AM, <ru...@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
>
>
>
> 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
> For additional commands, e-mail: dev-help@ibatis.apache.org
>