You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ibatis.apache.org by "Clinton Begin (JIRA)" <ib...@incubator.apache.org> on 2009/02/20 08:49:02 UTC

[jira] Commented: (IBATIS-580) SQLExecutor plug-ins for iBATIS2

    [ 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.