MyBatis version

3.5.3

Database vendor and version

SQL Server 2012

Test case or example project

<select id="selectMultiResultSet" resultMap="AMap,BMap,BMap">

BMap javaType has a property aProperty

The ResultSets of the two BMap is different (with different columns), e.g

The first BMap ResultSet (BResultSet1) is columnA, columnB

The second BMap ResultSet (BResultSet2) is columnb, columnC

When the DefaultResultSetHandler encounter the BResultSet1, it'll cache the aProperty on the autoMappingsCache, When the DefaultResultSetHandler handle the BResultSet2 for the second BMap, it'll use the aProperty to retrieve value from BResultSet2, which doesn't exit, and JDBC Driver will complain The column name aProperty is not valid.

Possible fix

We can add a configuration attribute to 

<resultMap useAutoMappingsCache="true(Default)/false">
...
</resultMap>

And change method createAutomaticMappings in DefaultResultSetHandler a little bit like

private List<UnMappedColumnAutoMapping> createAutomaticMappings(ResultSetWrapper rsw, ResultMap resultMap, MetaObject metaObject, String columnPrefix) throws SQLException {
    final String mapKey = resultMap.getId() + ":" + columnPrefix;
    List<UnMappedColumnAutoMapping> autoMapping = null;
    if (resultMap.isUseAutoMappingsCache()) {
           autoMapping = autoMappingsCache.get(mapKey);
    }

Demo test on PR92

Comment From: harawata

Hello @GitHanter ,

Thanks for the demo project! It really helps. :)

I was aware that there might be issues like this caused by the auto-mapping cache. But I think it's easily worked around by adding a new result map which extends the original one.

<resultMap id="multiResultSetMap" type="test.User" autoMapping="true">
  <id column="id" />
  <result property="name" column="name" />
</resultMap>

<resultMap id="multiResultSetMapCopy" type="test.User" extends="multiResultSetMap">
</resultMap>

<select id="getMultipleResultSet"
  resultMap="anotherEntityMap,multiResultSetMap,multiResultSetMapCopy">
..

Compared to the proposed option, this approach seems better because you won't lose the benefit of auto-mapping cache. What do you think?

Comment From: GitHanter

Yes, this work around can solve this problem, but some of our legacy project has four to five ResultSets mapped to the same ResultMap, and it'll be nice to have this configuration to turn the automapping cache off.

Anyway, you are right, this can solve the issue and use the automapping cahe to maximize performance. Thanks.

Comment From: harawata

Closing for now. We might reconsider if this turned out to be a frequently requested feature.