Skip to main content

7.2 Result Processing Rules

Result rules post-process query results and provide auxiliary handling for complex scenarios such as stored procedures. These rules themselves do not affect SQL generation; they only guide dbVisitor on how to map the returned data.

RuleDescription
@{resultSet}Configure result set mapping strategy (for stored procedures/multiple result sets).
@{resultUpdate}Mark a result as an update count (not a result set).
@{defaultResult}Configure default result set mapping strategy.

RESULTSET Rule​

In Stored Procedure or Multiple Result Set Query scenarios, guides dbVisitor on how to map the returned result sets.

Syntax: @{resultSet, key1 = value1, key2 = value2}

Supported Scenarios:

Property Description:

NameTypeDescription
nameStringName of this result set in the returned Map.
javaTypeClassMap the result set to a Java type. See Object Mapping.
rowMapperRowMapperUse custom RowMapper to handle mapping.
rowHandlerRowCallbackHandlerUse custom RowCallbackHandler to handle each row.
extractorResultSetExtractorUse custom ResultSetExtractor to handle the entire result set.
Property Priority

When multiple mapping properties are configured, they take effect by priority: javaType > rowMapper > rowHandler > extractor; the first matching item takes priority.


RESULTUPDATE Rule​

Marks a returned result as an update count (rather than a result set), used to distinguish the type of results returned by stored procedures.

Syntax: @{resultUpdate, name = paramName}

NameTypeDescription
nameStringName of the update count in the result.

DEFAULTRESULT Rule​

@{defaultResult} is equivalent to the default configuration within one execution of @{resultSet}. When a query returns multiple result sets, you can use this rule to avoid repeating configurations for each result set.

Syntax: @{defaultResult, key1 = value1, key2 = value2}

Property Description: Supports javaType, rowMapper, rowHandler, extractor, meaning same as above.