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 2005/03/06 05:41:52 UTC

[jira] Commented: (IBATIS-84) Enhancement proposal: plug in external bean

     [ http://issues.apache.org/jira/browse/IBATIS-84?page=comments#action_60285 ]
     
Clinton Begin commented on IBATIS-84:
-------------------------------------


Tak, you know I respect you and I appreciate your needs.  But I'm going to be completely honest.  I am not a big fan of this idea.  It potentially adds a great deal of complexity to result mappings, possibly that are outside of the scope of iBATIS.  

I also have concerns about the naming conventions, as they aren't portable to the .NET implementation (i.e. "bean" is not a valid .NET term).

A similar request has been made before, with regard to allowing factories to create object instances.  

I'm not entirely opposed to such ideas, but I would like to ensure that if we do implement something along these lines that it is:

1) VERY simple.  That is, it should not require more than one additional attribute on the result mapping (if any at all), and it should not introduce too many new interfaces or methods.  

2) Portable to the .NET implementation.  iBATIS has a family now, and we have to respect it.  Let's be careful to avoid such terms like "Bean".  I'm also not a fan of naming classes after patterns, especially not more than one.  "ServiceLocatorBean" has at least 3 patterns in the name, and as a new user I'd wonder what the heck it does.  What is it really?

3) Not redundant.  Before we do anything further, I'd like to see some exploration of ways this can be achieved WITHOUT modifications to iBATIS.  If there is no way, then we'll look into it.  But I would like to see some effort applied here first.

Hopefully the others who were interested in the result object factories are watching the list and will see this, so they can contribute too.

Cheers,
Clinton

> Enhancement proposal: plug in external bean
> -------------------------------------------
>
>          Key: IBATIS-84
>          URL: http://issues.apache.org/jira/browse/IBATIS-84
>      Project: iBatis for Java
>         Type: New Feature
>   Components: SQL Maps
>     Versions: 2.0.9b
>     Reporter: Tak Yoshida

>
> Hello SQLMap development team,
> I would like to post this idea again,
> which was submitted to sourceforge forum last year.
> I believe this is not only for my case in real world, 
> and makes SQLMap more flexible. 
>  
> I have already done on 2.0.9b, and it works pretty well on my project.
> If you would reflect my proposal in the future SQLMap, that would be great. 
> thanks,
> Tak Yoshida
> -------- Here is the post on Oct 30th for 2.0.7 --------
> I found one thing I should ask,
> that is external service bean plug in feature for the complex object query. 
>  
> In my project, I need to use Oracle Object Cache Service for disributed  
> application environment. 
> and this cache will be managed outside of SQLMap framework, 
> which mean I cannot use SQLMap cache plugin mechanism where SQLMap manages 
> cache object itself.
>  
> So I would like to have SQLMap call external service for complex object's sub 
> query. 
>  
> Here is my proposal:
> Summary: 
> Inject ServiceLocator to make SQLMap be able to call the service managed  
> outside of SQLMap. 
>  
> 1: To make use of external object, SqlMapClient has UserServiceBeanLocator 
> object property. 
>  
> public interface SqlMapClient extends SqlMapExecutor,  
> SqlMapTransactionManager { 
> public void setUserServiceBeanLocator(UserServiceBeanLocator 
> serviceBeanLocator); 
> public UserServiceBeanLocator getUserServiceBeanLocator(); 
> .... 
> } 
> And SqlMapClientImpl has this imlementation. 
>  
> public interface UserServiceBeanLocator { 
> // locator method 
> public Object getUserServiceBean(String name) throws SqlMapException; 
> } 
>  
>  
> 2: Extends resultMap's "result" tag attribute to specify the external bean 
> and the method name. 
>  
> <result property="shipMode" column="SMODE" javaType="string" 
> bean="shipModeDao" method="getShipModeById"/> 
> instead of 
> <result property="shipMode" column="SMODE" 
> select="shipModeSqlMap.getShipModeById"/> 
>  
> 3: To support 2, DTD must be enhanced for new two attributes, and  
> XmlSqlMapClientBuilder must support it. --> SQLMapParser on 2.0.9b
>  
> 4: And to hold these external bean info in mapping object created by 
> XmlSqlMapClientBuilder, 
> I introduce UserServiceBeanInfo. 
> public class UserServiceBeanInfo { 
> private String beanName; 
> private String methodName; 
> private Method method; 
> ... 
> } 
>  
> 5: Utilizing aboves, BasicResultMap.getResults() method can do nested quesry 
> for the complex property by calling external service. 
>  
> Here is a snippet of the codes 
> } else if (mapping.getUserServiceBeanInfo() != null) { 
> // get key for complex property 
> Object rawValue = getPrimitiveResultMappingValue(rs, mapping); 
> // get complex property via external service 
> UserServiceBeanLocator serviceBeanLocator =  
> request.getSession().getSqlMapClient().getUserServiceBeanLocator(); 
> UserServiceBeanInfo serviceBeanInfo = mapping.getUserServiceBeanInfo(); 
> try { 
> Object service = 
> serviceBeanLocator.getUserServiceBean(serviceBeanInfo.getBeanName()); 
> Method method = serviceBeanInfo.getMethod(); // check cacheed one. 
> if (method == null) { 
> method = service.getClass().getMethod(serviceBeanInfo.getMethodName(), new 
> Class[] {mapping.getJavaType()}); 
> serviceBeanInfo.setMethod(method); // cache it. 
> } 
> columnValues[i] = method.invoke(service, new Object[] {rawValue}); 
> ... exception handling... 
> } else { 
>  
> 6: Application is fully responsible to set this up at startup time. 
> I am injecting spring ApplicationContext object to SqlMapClient via 
> ApplicationListener, 
> -------------------------------

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira