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

View raw message