jungho-git/mybatis

MyBatis

• Shared examples and formatting reference: references/EXAMPLE.md.
• Keep new guidance, snippets, and edits aligned with that file.

Scope

Use this rule when:

• editing MyBatis mapper XML files
• changing mapper interfaces tied to mapper XML
• editing embedded SQL inside mapper XML
• changing namespace, statement id, parameterType, resultType, or resultMap
• reviewing dynamic SQL branches or parameter binding

MyBatis edits should preserve mapper interface, XML, SQL, and caller contracts.

Core Rules

• Preserve mapper namespace unless intentionally changing the Java interface contract.
• Match existing indentation; use 2 spaces when no local pattern exists.
• Do not self-close statement elements whose content model expects SQL or dynamic children.
• Preserve CDATA unless changing literal content requires it.
• Use #{...} bindings for values; use ${...} only for vetted identifiers that cannot be parameter-bound.
• Validate XML well-formedness after structural edits.

Mapper Contract

• Treat mapper interface and XML as one contract.
• Keep namespace, statement id, parameterType, resultType, and resultMap aligned.
• Preserve aliases and resultMap behavior callers depend on.
• Review <if>, <choose>, and <foreach> branches for null, empty, and optional input.
• Do not create <sql> snippets unless requested or genuinely repeated clauses require them.

Layering

• Mapper XML is for retrieval and persistence.
• Business logic belongs in Java or application code.
• Do not move format conversion, string manipulation, calculations, or code mapping into mapper XML queries.

Formatting

• Use one attribute per line when an element has more than two attributes.
• Put closing tags on their own line for block children.
• Use exactly one space around binary operators inside embedded SQL and OGNL expressions.
• Never vertically align attributes or embedded expressions.
• Keep compact standard style.

Validation Focus

• namespace correctness
• mapper method name vs statement id
• parameter and result shape
• embedded SQL parameter binding
• dynamic branch behavior
• well-formedness and schema/DTD validation when available