Failover to an XML mapping under a different namespace

[GoogleCodeExporter]

What version of the MyBatis are you using?
3.0.1

Please describe the problem.

There are 2 separate mapper interfaces with 2 separate XML mapping files which 
are organised by namespace to keep them separate. These 2 mappers have a common 
method name... let's call it getStuff();

When both mapper.xml files contain the <select id="getStuff"... /> element 
everything works as expected and the namespaces are upheld. However when the 
<select id="getStuff" element was removed from namespace1.xml, but not from 
MapperInterface1.java something unexpected happens.

What is the expected output? What do you see instead?

I expected to see an error thrown indicating that the "statements collection 
does not contain value for "namespace1.MapperInterface1.getStuff". However no 
exception was reported, instead the method returned an appropriate data object 
type, however that object was populated with data returned from the 
namespace2.xml sql statement!

In other words, when the SqlSession is resolving the interface method names 
with the sql mapping files, it appears to use the fully qualified namespace 
declaration first but then to fall back to short hand. 

According to the MyBatis-3-User-Guide

"  Fully qualified names (e.g. “com.mypackage.MyMapper.selectAllThings”) 
are looked up directly and used if found.
  Short names (e.g. “selectAllThings”) can be used to reference any unambiguous entry.
  However if there are two or more (e.g. “com.foo.selectAllThings and
com.bar.selectAllThings”), then you will receive an error reporting that the 
short name is ambiguous and therefore must be fully qualified." 

If I interpret this correctly, it indicates that the application should have 
either thrown the "ambiguous name" error in the first place when both 
namespaces contained the same method & statement name (if shorthand resolution 
was at play) or should have thrown the "name not found" error when the 
statement was removed from one of the namespaces (if fully qualified name was 
used). The fact that both succeeded is confusing and probably bad.

Original issue reported on code.google.com by pjewi...@gmail.com on 30 Sep 2010 at 2:27

• Merged into: #180

[GoogleCodeExporter]

This is really bad, since you must to be careful implementing the sql 
statements, in my case it loads the data with the correct Java object, but the 
data is from another table from the database.

Original comment by jda...@gmail.com on 8 Nov 2010 at 2:01

[GoogleCodeExporter]

See issue 180 for a suggested fix.

Here's why it happens.
http://groups.google.com/group/mybatis-user/browse_thread/thread/e6fe7509e12f653
4

Original comment by haraw...@gmail.com on 25 Nov 2010 at 5:15

[GoogleCodeExporter]

I think this is a duplicate of 180.
Can anyone try it and confirm that the issue is fixed?

Original comment by christia...@ircm.qc.ca on 14 Feb 2011 at 7:13

• Changed state: Duplicate

[GoogleCodeExporter]

Hi, I see the issue 180, is different.

I have the same problem in OC4J 10.1.3.3 with mybatis 3.0.6 and WLS 10.3.6 with 
mybatis 3.1.1 in both AppServer:
331  [AJPRequestHandler-RMICallHandler-6] ERROR Cabecera_EECC_Nacional - ERROR 
GRAVE GENERAL execCabecera_EECC_Nacional:
### Error updating database.  Cause: java.lang.IllegalArgumentException: 
cabecera_eecc_nacional is ambiguous in Mapped Statements collection (try using 
the full name including the namespace, or rename one of the entries)
### The error may exist in SqlMapConfig.xml
### Cause: java.lang.IllegalArgumentException: cabecera_eecc_nacional is 
ambiguous in Mapped Statements collection (try using the full name including 
the namespace, or rename one of the entries)
331  [AJPRequestHandler-RMICallHandler-8] ERROR Cabecera_EECC_Nacional - ERROR 
GRAVE GENERAL execCabecera_EECC_Nacional:
### Error updating database.  Cause: java.lang.IllegalArgumentException: Mapped 
Statements collection already contains value for EECC.detalle_eecc_nacional
### The error may exist in SqlMapConfig.xml
### Cause: java.lang.IllegalArgumentException: Mapped Statements collection 
already contains value for EECC.detalle_eecc_nacional

The one workaround is restart the application.

Original comment by Mario.Ar...@gmail.com on 29 Apr 2013 at 8:44

[GoogleCodeExporter]

Restarting the application seems drastic. If it works, it might be because a 
mapper is loaded again at some point during the application's execution.
Do you have a unit test that shows the problem?

Original comment by christia...@gmail.com on 30 Apr 2013 at 2:19

[GoogleCodeExporter]

No, this issue occur after 6 or 8 weeks working in production.
The period of the application in QA worked well.

Original comment by Mario.Ar...@gmail.com on 30 Apr 2013 at 3:08

[GoogleCodeExporter]

Hi,
Can you post the code that fails? I am especially interested in knowing if you 
use any statement without namespace.
If you do, I suggest you use the full qualified name of the statement.

Original comment by christia...@ircm.qc.ca on 3 May 2013 at 12:39

[GoogleCodeExporter]

this?

      <resultMap id="RSP_DATA" type="cl.bice.dao.out.Operaciones_RBC_OUT_Consulta_op">
        <result property="COR_ID_OPERACION" column="COR_ID_OPERACION"/>
        <result property="NUM_CONTEXTO_RBC" column="NUM_CONTEXTO_RBC"/>
        <result property="NUM_CONTEXTO_STF" column="NUM_CONTEXTO_STF"/>
        <result property="GLS_CUENTA" column="GLS_CUENTA"/>
        <result property="GLS_TARJETA" column="GLS_TARJETA"/>
        <result property="FEC_CONTABLE" column="FEC_CONTABLE"/>
        <result property="FEC_REGISTRO" column="FEC_REGISTRO"/>
        <result property="COD_TRX" column="COD_TRX"/>
        <result property="COD_TIPO_TRX" column="COD_TIPO_TRX"/>
        <result property="FLG_ESTADO" column="FLG_ESTADO"/>
        <result property="NUM_REFERENCIA" column="NUM_REFERENCIA"/>
        <result property="MTO_OPERACION" column="MTO_OPERACION"/>
        <result property="HOSTNAME" column="HOSTNAME"/>
        <result property="INSTANCEID" column="INSTANCEID"/>
        <result property="REINTENTO" column="ESTADO"/>
        <result property="MSJ_RBC" column="MSJ_RBC"/>
      </resultMap>
    <select id="consulta_op"
            parameterType="cl.bice.dao.in.Operaciones_RBC_Consulta_op"
            statementType="CALLABLE">
            { #{RSP, mode=OUT, jdbcType=CURSOR, javaType=java.sql.ResultSet, resultMap=RSP_DATA} = call RBC_PAC_OPERACIONES.CONSULTA_OP(
                  #{COR_ID_OPERACION, mode=IN, jdbcType=VARCHAR},
                  #{NUM_CONTEXTO_RBC, mode=IN, jdbcType=VARCHAR},
                  #{NUM_CONTEXTO_STF, mode=IN, jdbcType=VARCHAR},
                  #{GLS_CUENTA, mode=IN, jdbcType=VARCHAR},
                  #{GLS_TARJETA, mode=IN, jdbcType=VARCHAR},
                  #{FEC_CONTABLE, mode=IN, jdbcType=VARCHAR},
                  #{COD_TRX, mode=IN, jdbcType=VARCHAR},
                  #{COD_TIPO_TRX, mode=IN, jdbcType=VARCHAR},
                  #{FLG_ESTADO, mode=IN, jdbcType=VARCHAR},
                  #{NUM_REFERENCIA, mode=IN, jdbcType=VARCHAR},
                  #{MTO_OPERACION, mode=IN, jdbcType=VARCHAR},
                  #{HOSTNAME, mode=IN, jdbcType=VARCHAR},
                  #{INSTANCEID, mode=IN, jdbcType=VARCHAR},
                  #{REINTENTO, mode=IN, jdbcType=VARCHAR},
                  #{MSJ_RBC, mode=IN, jdbcType=VARCHAR}
                  ) }
    </select>

Original comment by Mario.Ar...@gmail.com on 7 May 2013 at 7:20

[GoogleCodeExporter]

I wasn't clear enough. I need enough code to try to produce a unit test.
I need the configuration file (either Java code or XML depending on your 
configuration) and the method that calls YourMapper.consulta_op().
Thanks for the mapper's XML, I will definitely use it.

Original comment by christia...@ircm.qc.ca on 7 May 2013 at 8:13

[GoogleCodeExporter]

Can I send to your email?

Original comment by Mario.Ar...@gmail.com on 7 May 2013 at 8:39

[GoogleCodeExporter]

Sure.

Original comment by christia...@ircm.qc.ca on 8 May 2013 at 2:25

[GoogleCodeExporter]

Did you try on the last version if the bug is still present? Many bugs were 
solved since 3.0.6.

Original comment by christia...@ircm.qc.ca on 8 May 2013 at 2:26