This is the 20th day of my participation in the November Gwen Challenge. Check out the details: The last Gwen Challenge 2021

In the article yesterday if in accordance with the system paging tool learning – PageHelper eight “, we in AbstractHelperDialect. BeforePage method was found in a variable Page, And you know that PageHelper is subtly passed as a thread-local variable via ThreadLocal .

Today we continue by looking at what logic the program performs after determining the need for paging through the beforePage method.

Then look at the pageQuery method of the ExecutorUtil class:

    public static <E> List<E> pageQuery(Dialect dialect, Executor executor, MappedStatement ms, Object parameter, RowBounds rowBounds, ResultHandler resultHandler, BoundSql boundSql, CacheKey cacheKey) throws SQLException {
        // Determine whether paging queries are required
        if (dialect.beforePage(ms, parameter, rowBounds)) {
            // Generate a cache key for paging
            CacheKey pageKey = cacheKey;
            // Process the parameter object
            parameter = dialect.processParameterObject(ms, parameter, boundSql, pageKey);
            / /... Other code is not posted temporarily

}
Copy the code

The next line of code comments the cacheKey that generates paging, and assigns the parameter cacheKey to the local variable pageKey without further elaboration.

Immediately following the next line:

// Process the parameter object
parameter = dialect.processParameterObject(ms, parameter, boundSql, pageKey);
Copy the code

This line of code calls the Dialect processing parameter method to process the parameter and reassign the return value to the parameter parameter.

Let’s take a closer look at the argument processing logic.

From the last few articles, we’ve seen the MysqlDialect class hierarchy:

Dialect -> AbstractDialect -> AbstractHelperDialect -> MySqlDialect

We found an implementation in AbstractHelperDialect at the most recent layer:

@Override
public Object processParameterObject(MappedStatement ms, Object parameterObject, BoundSql boundSql, CacheKey pageKey) {
        // Process parameters
        // Specific code....
}
Copy the code

Let’s look at the processing logic line by line:

// Process parameters
Page page = getLocalPage();
// If it is just order by, there is no need to handle arguments
if (page.isOrderByOnly()) {
    return parameterObject;
}
Copy the code

Page parameters are not described, but are described in detail in PageHelper 8.

There’s a weird point here or maybe it’s code style, but by retrieving orderByOnly I don’t see any code logic that would set it to false under any circumstances, in other words, currently orderByOnly defaults to false, The only way to call setOrderByOnly is to call setOrderByOnly(true)

Read on:

Map<String, Object> paramMap = null;
if (parameterObject == null) {
    paramMap = new HashMap<String, Object>();
} else if (parameterObject instanceof Map) {
    // Resolve the immutable Map case
    paramMap = new HashMap<String, Object>();
    paramMap.putAll((Map) parameterObject);
} else {
    /// In other cases the code is..... omit
}
return processPageParameter(ms, paramMap, page, boundSql, pageKey);
Copy the code

The first two ifs handle null arguments and map arguments.

The following code involves a number of parameter related classes, not explained at the moment. Our primary concern is still SQL changes.