Skip to main content
Hint

This article is generated by AI translation.

Rule Nesting

In dbVisitor, rules can be nested within each other. The parsing engine follows a "Depth First" strategy during recursive traversal. Using this feature, you can combine different rules to implement parameter pre-processing, conditional combinations, and other complex logic without writing additional processing logic in Java code.

Basic Usage​

The nested syntax takes the form of calling another rule @{...} within the parameter or content part of a rule.

@{ OuterRuleName, ..., @{ InnerRuleName, ... } ... }

For example, convert the user-input plain text password to MD5 before splicing it into SQL.

-- Original parameter :pwd = '123456'
@{and, password = @{md5, :pwd}}

Execution Flow:

  1. Inner Evaluation: @{md5, :pwd} is executed, calculating the MD5 value and registering it as a SQL parameter (generates placeholder ?).
  2. Outer Evaluation: The placeholder text generated by the inner layer participates in the splicing of the outer @{and} rule.
  3. Final SQL: AND password = ? (The actual parameter value executed is the MD5 hashed string).

Nesting Levels​

dbVisitor does not strictly limit the nesting level, but for readability and maintainability, it is recommended not to nest too deeply (more than 3 levels).

The following example shows how to combine @{and}, @{case}, and @{md5} to implement complex dynamic logic:

-- Scenario: Decide whether to query with MD5 encryption based on the encryptMode parameter
-- And the entire query condition is wrapped in AND
-- Note: The first parameter of @{case} is an OGNL expression, referencing the variable name directly (no colon needed)
@{and, password = @{case, encryptMode,
           @{when, true,  @{md5, :pwd}},   -- Mode on: Use MD5 processing and bind parameters
           @{else,        :pwd}            -- Mode off: Bind original parameters directly
       }
}

Parsing Process:

  1. Dispatch Logic: @{case} matches based on the value of encryptMode.
  2. Value Calculation:
    • If matches true, execute @{when} containing @{md5, :pwd}, calculating MD5 and generating parameter placeholder ?.
    • Otherwise (@{else}), execute the contained :pwd, also generating parameter placeholder ?.
  3. Final Splicing: @{and} splices the result into SQL: AND password = ?.

Usage Notes​

Avoid Single Quotes Wrapping Rules

Do not wrap single quotes around rules, especially when the rule (such as @{md5}, @{uuid}) itself is used to generate parameter placeholders.

  • Correct: pwd = @{md5, :val} -> Generates pwd = ? (Passed via PreparedStatement, safe and correct)
  • Incorrect: pwd = '@{md5, :val}' -> Generates pwd = '?' (Treated as string literal, functionality fails)
Execution Order

Rules are always calculated from the inner layer first, then the outer layer. If the inner rule does not generate any content (returns an empty string) because the condition is not met, the outer rule receives an empty string.