ibatis-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Clinton Begin (JIRA)" <ibatis-...@incubator.apache.org>
Subject [jira] Commented: (IBATIS-580) SQLExecutor plug-ins for iBATIS2
Date Fri, 20 Feb 2009 07:49:02 GMT

    [ https://issues.apache.org/jira/browse/IBATIS-580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12675273#action_12675273
] 

Clinton Begin commented on IBATIS-580:
--------------------------------------

I should be able to look at this in the next two weeks.

> SQLExecutor plug-ins for iBATIS2
> --------------------------------
>
>                 Key: IBATIS-580
>                 URL: https://issues.apache.org/jira/browse/IBATIS-580
>             Project: iBatis for Java
>          Issue Type: Improvement
>          Components: SQL Maps
>    Affects Versions: 2.3.4
>         Environment: Platform independent
>            Reporter: Abhigyan Agrawal
>             Fix For: 2.3.4
>
>         Attachments: junitResults.tar, plugin.patch, src.tar
>
>
> The attached patch file provides the ability in to override the default 'SQLExecutor'
if required in v2.
> No new test cases need to be added for this functionality, since the existing test cases
regress these changes. Attached are the ibatis test suites results executed with these changes.
> ______________________________________________________________
> Attachments:
> junitResults.tar - iBATIS test suite results with plug-in changes.
> src.tar - Source for plug-in changes.
> plugin.patch - patch file for plug-in changes.
> ______________________________________________________________
> Usage Description
>     * User defines a property 'sqlExecutor'  in the iBatis properties file. The value
is set to the name of the class (user developed) that implements the interface com.ibatis.sqlmap.engine.execution.ISqlExecutor
> Description of code changes 
>   1. com.ibatis.sqlmap.engine.execution.ISqlExecutor 
>        -  new interface which consists of all the public methods of the the default SQLExecutor
in iBATIS - com.ibatis.sqlmap.engine.execution.SqlExecutor
>   2. com.ibatis.sqlmap.engine.execution.SqlExecutor
>        The default SQLExecutor now implements the ISqlExecutor interface
>   3. com.ibatis.sqlmap.engine.impl.SqlMapExecutorDelegate
>        - Changed the type of the member variable 'sqlExecutor' to the interface ISqlExectuor
>        - changed return type of method getSqlExecutor() to ISqlExecutor from SqlExecutor
>        - added method setCustomExecutor(string sqlExecutorClass).
>               **Instantiates user specified class that implements interface com.ibatis.sqlmap.engine.execution.SqlExecutor
>   
>    4. com.ibatis.sqlmap.engine.impl.SqlMapSessionImpl.java, ExtendedSqlMapClient.java,
SqlMapClientImpl.java, com.ibatis.sqlmap.engine.mapping.statement.MappedStatement	
>         - changed the return type of method getSqlExecutor() to ISqlExecutor from SqlExecutor
>    5. com.ibatis.sqlmap.engine.builder.xml.XmlParserState
> 	setGlobalProperties() - If the 'sqlExecutor' property is defined in the properties file,
reads it and invokes SqlMapExecutorDelegate.setCustomExecutor(valueOfDefinedSqlExecutor)
> ** The SqlMapExecutorDelegate instantiates the default SQLExecutor in its constructor.
Initially had removed this and had the sqlExecutor always instantiated via a setter. With
this XmlParserState.setGlobalProperties() always called the setter, to instantiate the Default
or user-overridden sqlExecutor. The problem with this was that it is not mandatory to have
a ibatis properties file, in which case the XmlParserState.setGlobalProperties() is not invoked.
Given the parsing logic, couldn't find a appropriate place to invoke the getter to instantiate
the default SQLExecutor and reverted to having it instantiated in the constructor
>   setCustomExecutor re-initializes the 'sqlExecutor'. Assumed this is OK, since it is
always invoked during config setup and hence also the reinitialization doesn't need to be
synchronized.
> * It could have been possible to have this via a new property defined in the SqlMapConfig.xml.
However given how many folks are probably going to use it, and the amount of changes, chose
the property file approach.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message