To accomplish this you'll need to skip the parameter map and use the advanced inline parameter syntax.  Here's an example:
 
SQL Map
 
<procedure id="dynamic_package_id" parameterClass="map">
  { call $packageName$.get_key_2_out_basic( #outParam,javaType=java.lang.Integer,mode=OUT,jdbcType=INTEGER# ) }
</procedure>
 
 
Java

 

Map parms = new HashMap();
parms.put("packageName", "ut_Tipo_dato");

sqlMapClient.update("dynamic_package_id", parms);
Integer result = (Integer) parms.get("outParam");

 
Jeff Butler
 

 
On 10/12/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:

[EMAIL PROTECTED] scritti il 12/10/2006 13:36:36

> Put the bean in the Map, call it "bean" and refer to it's properties
> in the mapped statement (or parameter map) with a "bean." prefix:
> "bean.someProperty".
>
> There are not many examples of the Java code because it's pretty much
> all the same:
>
> sqlMapClient.almostAnyMethod("namespace.statement", parameterObject);

Thanks Larry.
I tried to interpret your suggestion

Firstly I tried this

<parameterMap id="paraMap" class="it.finmatica.gpj.aa.frontebd.ChiaveBean">
<parameter value="outParam" property="id" jdbcType="INTEGER" javaType="int" mode="OUT"/>
</parameterMap>
 
<procedure id="dynamic_package_id" parameterMap="paraMap">
{ call $packageName$.get_key_2_out_basic( ? ) }
</procedure>

(I read the "value" techinque for Maps in the list somewhere but, unfortunately I do not find it anymore)
with this Java code

HashMap< String, Object > lHashMap = new HashMap< String, Object >();
    ChiaveBean lChiaveBean = new ChiaveBean( 1234 );
[*]    lHashMap.put( "outParam", lChiaveBean );
    lHashMap.put( "packageName", new String( "ut_Tipo_dato" ) );
      try
        {
        lSqlMapClient.update( "dynamic_package_id", lHashMap );

(the doubt here was "how can I pass the parameter for $packageName$?", so I tried by adding a second item to that map with the "packageName" key) and the diagnostic)
The diagnostic complained about the value for the "parameter" element type.

    [...] Error parsing XML.  Cause: org.xml.sax.SAXParseException: Attribute "value" must be declared for element type "parameter".


I've removed the "value" element type (infact, the syntax for parameterMaps does not accept it) an I got
    --- The error occurred in it/finmatica/gpj/aa/frontebd/DynamicTableTest.xml.  
    --- The error occurred while preparing the mapped statement for execution.  
    --- Check the dynamic_package_id.  
    --- Cause: java.sql.SQLException : Invalid parameter object type.  Expected 'it.finmatica.gpj.aa.frontebd.ChiaveBean' but found 'java.util.HashMap'.
iBatis complains that wants a ChiaveBean
Well, if I pass a ChiaveBean, how can I provide the $packageName$?
Anyway, let's try
    --- The error occurred in it/finmatica/gpj/aa/frontebd/DynamicTableTest.xml.  
    --- The error occurred while preparing the mapped statement for execution.  
    --- Check the dynamic_package_id.  
    --- Check the SQL statement.  
    --- Cause: com.ibatis.common.beans.ProbeException: There is no READABLE property named 'packageName' in class 'it.finmatica.gpj.aa.frontebd.ChiaveBean '

iBatis searches the ChiaveBean for a packageName property.
I'm beginning to think that I should write a suitable JavaBean to provide a property packageName, as well... :( Right?
We have some JavaBeans classes whose structure reflect the data on the DB and we would prefer not to pollute them with data needed to dinamically generate the SQL statements (we might extend the JavaBean classes but it would be, anyway, an extrema ratio)


Is anywayt to keep distinct the parameters for the procedure (parameterMap + a suitable Java Bean)
and the parameters to be used to make the SQL statement, such as $packageName$?
Perhaps using a HashMap and the actual parameters passed with their name as depicted above ( [*])?


ciao
Cesare


Reply via email to