2. 程式人生 > >Mybatis原始碼分析（7）—— 結果集處理

Mybatis原始碼分析（7）—— 結果集處理

阿新 • • 發佈：2018-10-31

解析封裝

ResultMap 是和結果集相關的東西，最初在解析 XML 的時候，於 parseStatementNode 方法中，針對每一個 select 節點進行解析，轉換為 MappedStatement（類似 Spring 的 bean 配置和 BeanDefinition 的關係）。

在 MapperBuilderAssistant 的 addMappedStatement 方法中，構建完statementBuilder，會呼叫 setStatementResultMap 方法給其設定 ResultMap。

setStatementResultMap(resultMap, resultType, resultSetType, statementBuilder);

private void setStatementResultMap(
      String resultMap,
      Class<?> resultType,
      ResultSetType resultSetType,
      MappedStatement.Builder statementBuilder) {
    resultMap = applyCurrentNamespace(resultMap, true);

    List<ResultMap> resultMaps = new ArrayList<ResultMap>();
    if
 
 (resultMap != null) {
      String[] resultMapNames = resultMap.split(",");
      for (String resultMapName : resultMapNames) {
        try {
          resultMaps.add(configuration.getResultMap(resultMapName.trim()));
        } catch (IllegalArgumentException e) {
          throw new IncompleteElementException("Could not find result map "
 
 + resultMapName, e);
        }
      }
    } else if (resultType != null) {
      ResultMap.Builder inlineResultMapBuilder = new ResultMap.Builder(
          configuration,
          statementBuilder.id() + "-Inline",
          resultType,
          new ArrayList<ResultMapping>(),
          null);
      resultMaps.add(inlineResultMapBuilder.build());
    }
    statementBuilder.resultMaps(resultMaps);

    statementBuilder.resultSetType(resultSetType);
}

首先檢查 resultMap，根據名稱去 configuration 中取出對應的 resultMap 放到集合中；

如果 resultMap 不存在，就檢查 resultType ，然後利用這個 resultType 構造一個 resultMap，如果兩個都沒有，那就走著瞧（resultMaps集合為空）。

中期呼叫

在 PreparedStatementHandler 的 query 方法中：

public <E> List<E> query(Statement statement, ResultHandler resultHandler) throws SQLException {
    PreparedStatement ps = (PreparedStatement) statement;
    ps.execute();
    return resultSetHandler.<E> handleResultSets(ps);
}

而 resultSetHandler 於基類 BaseStatementHandler 中構造：

this.resultSetHandler = configuration.newResultSetHandler(executor, mappedStatement, rowBounds, parameterHandler, resultHandler, boundSql);

根據是否有巢狀的 ResultMaps 來確定建立 NestedResultSetHandler 還是 FastResultSetHandler:

public ResultSetHandler newResultSetHandler(Executor executor, MappedStatement mappedStatement, RowBounds rowBounds, ParameterHandler parameterHandler,
      ResultHandler resultHandler, BoundSql boundSql) {
    ResultSetHandler resultSetHandler = mappedStatement.hasNestedResultMaps() ? new NestedResultSetHandler(executor, mappedStatement, parameterHandler, resultHandler, boundSql,
        rowBounds) : new FastResultSetHandler(executor, mappedStatement, parameterHandler, resultHandler, boundSql, rowBounds);
    resultSetHandler = (ResultSetHandler) interceptorChain.pluginAll(resultSetHandler);
    return resultSetHandler;
}

影響這個判斷的有幾個點：

  • 解析時期
public Builder resultMaps(List<ResultMap> resultMaps) {
  mappedStatement.resultMaps = resultMaps;
  for (ResultMap resultMap : resultMaps) {
    mappedStatement.hasNestedResultMaps = mappedStatement.hasNestedResultMaps || resultMap.hasNestedResultMaps();
  }
  return this;
}
  • getBoundSql時期
for (ParameterMapping pm : boundSql.getParameterMappings()) {
  String rmId = pm.getResultMapId();
  if (rmId != null) {
    ResultMap rm = configuration.getResultMap(rmId);
    if (rm != null) {
      hasNestedResultMaps |= rm.hasNestedResultMaps();
    }
  }
}

後期處理

NestedResultSetHandler繼承自FastResultSetHandler ，二者在handleResultSets是一致的（只是重寫了 handleRowValues 等方法）：

public List<Object> handleResultSets(Statement stmt) throws SQLException {
    final List<Object> multipleResults = new ArrayList<Object>();
    final List<ResultMap> resultMaps = mappedStatement.getResultMaps();
    int resultMapCount = resultMaps.size();
    int resultSetCount = 0;
    ResultSet rs = stmt.getResultSet();

    while (rs == null) {
      // move forward to get the first resultset in case the driver
      // doesn't return the resultset as the first result (HSQLDB 2.1)
      if (stmt.getMoreResults()) {
        rs = stmt.getResultSet();
      } else {
        if (stmt.getUpdateCount() == -1) {
          // no more results.  Must be no resultset
          break;
        }
      }
    }
    // 驗證是否定義了resultType或者resultMap
    validateResultMapsCount(rs, resultMapCount);
    while (rs != null && resultMapCount > resultSetCount) {
      final ResultMap resultMap = resultMaps.get(resultSetCount);
      ResultColumnCache resultColumnCache = new ResultColumnCache(rs.getMetaData(), configuration);
      handleResultSet(rs, resultMap, multipleResults, resultColumnCache);
      rs = getNextResultSet(stmt);
      cleanUpAfterHandlingResultSet();
      resultSetCount++;
    }
    return collapseSingleResultList(multipleResults);
}

處理模板

  • validateResultMapsCount

resultMapCount 就是之前解析時構造的那個 ResultMap 集合的 size，如果沒有配置 ResultMap 或 ResultType，這裡就要報錯了：

A query was run and no Result Maps were found for the Mapped Statement ……

  • handleResultSet

傳入構建的List型別的集合 multipleResults，呼叫 handleRowValues 處理從 ResultSet 獲取的結果集。

  • collapseSingleResultList

這個就不說了。

細節分析

FastResultSetHandler 用得相對較多，這裡只針對其 handleRowValues 處理結果行進行分析：

protected void handleRowValues(ResultSet rs, ResultMap resultMap, ResultHandler resultHandler, RowBounds rowBounds, ResultColumnCache resultColumnCache) throws SQLException {
    final DefaultResultContext resultContext = new DefaultResultContext();
    skipRows(rs, rowBounds);
    while (shouldProcessMoreRows(rs, resultContext, rowBounds)) {
      final ResultMap discriminatedResultMap = resolveDiscriminatedResultMap(rs, resultMap, null);
      Object rowValue = getRowValue(rs, discriminatedResultMap, null, resultColumnCache);
      callResultHandler(resultHandler, resultContext, rowValue);
    }
}

1、RowBounds 與 分頁

skipRows 就是跳過行，基於查詢結果的分頁使用，其中會直接呼叫 ResultSet 的 absolute 方法：

rs.absolute(rowBounds.getOffset());

而 shouldProcessMoreRows 方法就是判斷是否應該獲取更多的行：

protected boolean shouldProcessMoreRows(ResultSet rs, ResultContext context, RowBounds rowBounds) throws SQLException {
    return !context.isStopped() && rs.next() && context.getResultCount() < rowBounds.getLimit();
}

也對應了分頁的limit欄位，這種分頁可以說是偽分頁，查出來再分頁。所以我們一般使用外掛的形式來實現分頁，基於sql的動態替換。

2、獲取行資料

如果應該獲取更多的行，就會逐行處理結果：

protected Object getRowValue(ResultSet rs, ResultMap resultMap, CacheKey rowKey, ResultColumnCache resultColumnCache) throws SQLException {
    final ResultLoaderMap lazyLoader = instantiateResultLoaderMap();
    Object resultObject = createResultObject(rs, resultMap, lazyLoader, null, resultColumnCache);
    if (resultObject != null && !typeHandlerRegistry.hasTypeHandler(resultMap.getType())) {
      final MetaObject metaObject = configuration.newMetaObject(resultObject);
      boolean foundValues = resultMap.getConstructorResultMappings().size() > 0;
      if (shouldApplyAutomaticMappings(resultMap, !AutoMappingBehavior.NONE.equals(configuration.getAutoMappingBehavior()))) {
        final List<String> unmappedColumnNames = resultColumnCache.getUnmappedColumnNames(resultMap, null);
        foundValues = applyAutomaticMappings(rs, unmappedColumnNames, metaObject, null, resultColumnCache) || foundValues;
      }
      final List<String> mappedColumnNames = resultColumnCache.getMappedColumnNames(resultMap, null);
      foundValues = applyPropertyMappings(rs, resultMap, mappedColumnNames, metaObject, lazyLoader, null) || foundValues;
      foundValues = (lazyLoader != null && lazyLoader.size() > 0) || foundValues;
      resultObject = foundValues ? resultObject : null;
      return resultObject;
    }
    return resultObject;
}

主要就是根據相關引數建立結果物件，這裡又分多鐘情況：

  • 原始物件的處理（如 Integer 等基本型別物件）

利用 ResultMap 中儲存的返回結果型別資訊，直接返回相應的值。

  • 非原始物件（是自定義的物件）處理

運用反射構造實體物件（相當於一個帶有零值的初始物件）。然後用該物件構造一個 MetaObject ，並檢視是否需要根據對映自動填充物件。

如果需要通過自動對映來填充，取出 List 型別的屬性名，根據這個同 SQL 中查出來一致的欄位名，去 ResultSet 中拿出來然後填充到物件中，相關程式碼如下：

final String property = metaObject.findProperty(propertyName, configuration.isMapUnderscoreToCamelCase());
if (property != null) {
    final Class<?> propertyType = metaObject.getSetterType(property);
    if (typeHandlerRegistry.hasTypeHandler(propertyType)) {
       final TypeHandler<?> typeHandler = resultColumnCache.getTypeHandler(propertyType, columnName);
       final Object value = typeHandler.getResult(rs, columnName);
       if (value != null || configuration.isCallSettersOnNulls()) { // issue #377, call setter on nulls
          metaObject.setValue(property, value);
          foundValues = true;
       }
    }
}

這個處理完後，才是非對映列的處理。

3、結果對映

resultMap 元素是 MyBatis 中最重要最強大的元素。它可以讓你從 90% 的 JDBC ResultSets 資料提取程式碼中解放出來, 並在一些情形下允許你做一些 JDBC 不支援的事情。

在 handleResultSets 方法中，取 ResultSet 元資訊構造了一個 ResultColumnCache：

ResultColumnCache resultColumnCache = new ResultColumnCache(rs.getMetaData(), configuration);

後面在對映列的時候分別呼叫了 getUnmappedColumnNames 和 getMappedColumnNames 方法來取列集合，對應於 ResultColumnCache 的 unMappedColumnNamesMap 和 mappedColumnNamesMap。如果集合為空，將呼叫下面的方法來構造：

private void loadMappedAndUnmappedColumnNames(ResultMap resultMap, String columnPrefix) throws SQLException {
    List<String> mappedColumnNames = new ArrayList<String>();
    List<String> unmappedColumnNames = new ArrayList<String>();
    final String upperColumnPrefix = columnPrefix == null ? null : columnPrefix.toUpperCase(Locale.ENGLISH);
    final Set<String> mappedColumns = prependPrefixes(resultMap.getMappedColumns(), upperColumnPrefix);
    for (String columnName : columnNames) {
        final String upperColumnName = columnName.toUpperCase(Locale.ENGLISH);
        if (mappedColumns.contains(upperColumnName)) {
          mappedColumnNames.add(upperColumnName);
        } else {
          unmappedColumnNames.add(columnName);
        }
    }
    mappedColumnNamesMap.put(getMapKey(resultMap, columnPrefix), mappedColumnNames);
    unMappedColumnNamesMap.put(getMapKey(resultMap, columnPrefix), unmappedColumnNames);
}

通常情況下，loadMappedAndUnmappedColumnNames 只會呼叫一次（多行結果的列名是一樣的），所以 ResultColumnCache 名副其實。

它區分是否是滿足對映的列名是根據 mappedColumns 集合中是否有來判斷的，而 mappedColumns 對應於 ResultMap 配置中的 column 屬性。

所以自動對映針對的是沒有配置 ResultMap 而使用了 ResultType 的情況；或者配置並使用了 ResultMap，但是 ResultMap 中的 column 屬性集合不包含實際SQL欄位名，也就是對不上的情況。這個時候是需要直接操作這個欄位名，可能需要去除下劃線等基於規則的演變，最後通過 MetaObject 來賦值。

那麼非自動對映呢？就是配置並使用了 ResultMap，這個簡單多了，直接按你配置的來，取 ResultMap 屬性配置下的 property 名稱，這個就是你實際的物件屬性名，然後也是通過 MetaObject 來賦值。

分析到這裡，已經比較明朗了，整體的脈絡也在腦海中勾勒出來了。ResultMap 實際遠不止這些，至於高階功能到時候用起來再具體分析吧。

相關推薦

Mybatis原始碼分析（7）—— 結果集處理

解析封裝 ResultMap 是和結果集相關的東西，最初在解析 XML 的時候，於 parseStatementNode 方法中，針對每一個 select 節點進行解析，轉換為 MappedStatement（類似 Spring 的 bean 配置和 BeanDefinition 的

Mybatis 原始碼分析（2）—— 引數處理

Mybatis對引數的處理是值得推敲的，不然在使用的過程中對發生的一系列錯誤直接懵逼了。 以前遇到引數繫結相關的錯誤我就是直接給加@param註解，也稀裡糊塗地解決了，但是後來遇到了一些問題推翻了我的假設：單個引數不需要使用 @param 。由此產生了一個疑問，Mybatis到底是怎

Mybatis 原始碼分析（9）—— 事物管理

Mybatis 提供了事物的頂層介面： public interface Transaction { /** * Retrieve inner database connection * @return DataBase connection * @throw

Mybatis 原始碼分析（8）—— 一二級快取

一級快取 其實關於 Mybatis 的一級快取是比較抽象的，並沒有什麼特別的配置，都是在程式碼中體現出來的。 當呼叫 Configuration 的 newExecutor 方法來建立 executor： public Executor newExecutor(Transac

Mybatis原始碼分析（6）—— 從JDBC看Mybatis的設計

Java資料庫連線，（Java Database Connectivity，簡稱JDBC）是Java語言中用來規範客戶端程式如何來訪問資料庫的應用程式介面，提供了諸如查詢和更新資料庫中資料的方法。 六步流程: 載入驅動（5.x驅動包不需要這步了） 建立

Mybatis原始碼分析（5）—— 外掛的原理

MyBatis 允許你在已對映語句執行過程中的某一點進行攔截呼叫。 預設情況下，可以使用外掛來攔截的方法呼叫包括： Executor (update, query, flushStatements, commit, rollback, getTransaction, cl

Mybatis原始碼分析（4）—— Mapper的建立和獲取

Mybatis我們一般都是和Spring一起使用的，它們是怎麼融合到一起的，又各自發揮了什麼作用？ 就拿這個Mapper來說，我們定義了一個介面，聲明瞭一個方法，然後對應的xml寫了這個sql語句， 它怎麼就執行成功了？這傢伙是怎麼實現的，帶著這個好奇心，我一步步跟蹤，慢慢揭開了它的

Mybatis原始碼分析（3）—— 從Mybatis的視角去看Bean的初始化流程

不涉及Spring完整的啟動流程，僅僅從Mybatis的視角去分析幾個關鍵的方法，找到Mybatis是如何通過這幾個擴充套件點植入進去的，反過來看Spring是如何設計，埋下這些伏筆，實現其可擴充套件性。 springContext-mybatis.xml的配置： <!--

Mybatis原始碼分析（1）—— Mapper檔案解析

感覺CSDN對markdown的支援不夠友好，總是伴隨各種問題，很惱火！ xxMapper.xml的解析主要由XMLMapperBuilder類完成，parse方法來完成解析： public void parse() { if (!configuration.isRes

Netflix Eureka原始碼分析（7）——eureka client啟動環境初始化流程

eureka-examples，有一個類，ExampleEurekaClient，就是一個自帶的例子，如果是一個eureka服務，一定會有一個eureka client，服務例項啟動的時候，一定會啟動eureka client，eureka client去向eureka se

MyBatis原始碼分析（1）-MapConfig檔案的解析

1.簡述    MyBatis是一個優秀的輕ORM框架，由最初的iBatis演化而來，可以方便的完成sql語句的輸入輸出到java物件之間的相互對映，典型的MyBatis使用的方式如下： String resource = "org/mybatis/example/mybatis-config.xml";

nginx原始碼分析（7）——請求處理

        在建立連線過程中，對於nginx監聽到的每個客戶端連線，都會將它的讀事件的handler設定為ngx_http_init_request函式，這個函式就是請求處理的入口。在處理請求時，主要就是要解析http請求，比如：uri，請求行等，然後再根據請求生成響應

mybatis 原始碼分析（一）框架結構概覽

本篇部落格將主要對 mybatis 整體介紹，包括 mybatis 的專案結構，執行的主要流程，初始化流程，API 等各模組進行簡單的串聯，讓你能夠對 mybatis 有一個整體的把握。另外在 mybatis 原始碼的閱讀過程中，如果不想寫 demo 可以直接使用專案中的單元測試； 一、mybatis 結構介

mybatis 原始碼分析（二）mapper 初始化

mybatis 的初始化還是相對比較複雜，但是作者在初始化過程中使用了多種設計模式，包括建造者、動態代理、策略、外觀等，使得程式碼的邏輯仍然非常清晰，這一點非常值得我們學習； 一、mapper 初始化主要流程 mybatis 初始化的過程中，主要是 XML 配置的解析，不同的部分又分別委託給了不同的解析器；

mybatis 原始碼分析（四）一二級快取分析

本篇部落格主要講了 mybatis 一二級快取的構成，以及一些容易出錯地方的示例分析； 一、mybatis 快取體系 mybatis 的一二級快取體系大致如下： 首先當一二級快取同時開啟的時候，首先命中二級快取； 一級快取位於 BaseExecutor 中不能關閉，但是可以指定範圍 STATEMENT、

mybatis 原始碼分析（五）Interceptor 詳解

本篇部落格將主要講解 mybatis 外掛的主要流程，其中主要包括動態代理和責任鏈的使用； 一、mybatis 攔截器主體結構 在編寫 mybatis 外掛的時候，首先要實現 Interceptor 介面，然後在 mybatis-conf.xml 中新增外掛， <configuration>

mybatis 原始碼分析（六）StatementHandler 主體結構分析

分析到這裡的時候，mybatis 初始化、介面、事務、快取等主要功能都已經講完了，現在就還剩下 StatementHandler 這個真正幹活的傢伙沒有分析了；所以接下來的部落格內容主要和資料庫的關係比較密切，而 StatementHandler 的主要流程也基本是和 JDBC 的流程是一一對應的； 一、St

mybatis 原始碼分析（七）KeyGenerator 詳解

一、KeyGenerator 概述 在平時開發的時候經常會有這樣的需求，插入資料返回主鍵，或者插入資料之前需要獲取主鍵，這樣的需求在 mybatis 中也是支援的，其中主要的邏輯部分就在 KeyGenerator 中，下面是他的類圖： 其中： NoKeyGenerator：預設空實現，不需要對主鍵單獨處

mybatis 原始碼分析（八）ResultSetHandler 詳解

本篇部落格就是 myabtis 系列的最後一篇了，還剩 ResultSetHandler 沒有分析；作為整個 mybatis 最複雜最繁瑣的部分，我不打算按步驟一次詳解，因為裡面的主要內容就是圍繞 resultMap 按層次結構依次解析的，其中運用最多的就是反射，所以我這裡將圍繞延遲載入重點分析，另外本文使用

Spring component-scan原始碼分析（二） -- @Configuration註解處理

上篇文章Spring component-scan原始碼分析（一） – XML解析分析了Spring解析<context:component-scan …/>標籤時，把掃描到的合適的類封裝成BeanDefinition加入Sping容器中，本篇分析S