fix: Modify mapper #209
fix: Modify mapper #209
Conversation
WalkthroughThe changes across multiple MyBatis XML mapper files simplify conditional checks for various boolean or flag fields. Previously, these conditions tested for both non-nullity and non-empty string values (e.g., Changes
Sequence Diagram(s)sequenceDiagram
participant Client
participant Mapper
participant Database
Client->>Mapper: Submit query/update with parameters
Mapper->>Mapper: Check if field != null
alt Field is not null
Mapper->>Database: Include field in SQL WHERE/SET clause
else Field is null
Mapper->>Database: Exclude field from SQL clause
end
Database-->>Mapper: Return results/status
Mapper-->>Client: Return results/status
Poem
Tip ⚡💬 Agentic Chat (Pro Plan, General Availability)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
base/src/main/resources/mappers/ComponentMapper.xml (1)
75-83: Ensure query conditions are consistent
The corresponding<if>tests inComponentByConditionstill includeand isOfficial!='',and isDefault!='', andand isTinyReserved!=''. Consider removing these redundant empty‐string checks for consistency across your mapper.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (11)
base/src/main/resources/mappers/AppMapper.xml(5 hunks)base/src/main/resources/mappers/BlockHistoryMapper.xml(2 hunks)base/src/main/resources/mappers/BlockMapper.xml(2 hunks)base/src/main/resources/mappers/ComponentLibraryMapper.xml(2 hunks)base/src/main/resources/mappers/ComponentMapper.xml(1 hunks)base/src/main/resources/mappers/MaterialMapper.xml(4 hunks)base/src/main/resources/mappers/PageHistoryMapper.xml(4 hunks)base/src/main/resources/mappers/PageMapper.xml(4 hunks)base/src/main/resources/mappers/PageTemplateMapper.xml(4 hunks)base/src/main/resources/mappers/PlatformMapper.xml(4 hunks)base/src/main/resources/mappers/UserMapper.xml(4 hunks)
🔇 Additional comments (20)
base/src/main/resources/mappers/UserMapper.xml (1)
22-24: Simplify boolean flag condition checks
Removed redundant empty‐string (!='') comparisons for the flag fields (isEnable,isAdmin,isPublic) in both theUserByConditionandUserSetColumnsSQL fragments. Conditions now only test for!=null, which aligns with the intended wrapper‐type semantics and eliminates unnecessary string checks.Also applies to: 46-48, 49-51, 62-64, 87-89, 90-92
base/src/main/resources/mappers/AppMapper.xml (1)
85-87: Streamline boolean flag conditions in App mapper
Removed redundant empty‐string checks (!='') for boolean/flag fields (isDefault,canAssociate,isPublish,isDemo) across theAppByConditionandAppSetColumnsfragments. Now each<if>only verifies!=null, standardizing logic and reducing unnecessary evaluations.Also applies to: 115-117, 176-178, 209-210, 212-214, 242-244
base/src/main/resources/mappers/BlockMapper.xml (1)
57-59: Simplify block‐flag null checks
Dropped redundant!=''checks for the flag parameters (isOfficial,isDefault,isTinyReserved) in bothBlockByConditionandBlockSetColumns. Conditions now only test for non‐nullity, aligning with typed boolean semantics and improving readability.Also applies to: 63-68, 148-150, 154-159
base/src/main/resources/mappers/BlockHistoryMapper.xml (1)
56-58: Remove unnecessary empty‐string tests for history flags
Consolidated the<if>tests forisOfficial,isDefault, andisTinyReservedby removing!=''checks in both the condition (BlockHistoryByCondition) and update (BlockHistorySetColumns) fragments. Now they only validate!=null, matching the field definitions and simplifying the SQL.Also applies to: 62-67, 150-152, 156-161
base/src/main/resources/mappers/ComponentLibraryMapper.xml (1)
52-60: Streamline component‐library flag checks
Removed redundant empty‐string validations (!='') for the boolean/flag fields (isStarted,isOfficial,isDefault) in both theComponentLibraryByConditionandComponentLibrarySetColumnsfragments. Conditions now solely check!=null, which is appropriate for wrapper‐type parameters and cleans up the SQL mappings.Also applies to: 122-130
base/src/main/resources/mappers/ComponentMapper.xml (1)
172-180: Remove redundant empty-string checks for boolean flags in update fragment
The<if>conditions forisOfficial,isDefault, andisTinyReservednow correctly only test for non-null values, which is sufficient for boolean/flag fields.base/src/main/resources/mappers/PageTemplateMapper.xml (2)
25-30: Simplify boolean flag checks in query fragment
The<if>tests forpublished,publicStatus, andisPresetnow only verify!= null, which is appropriate for nullable boolean/flag fields.Also applies to: 37-39
83-88: Simplify boolean flag checks in update fragment
The<if>tests forpublished,publicStatus, andisPresethave been correctly updated to only check for non-null values inPageTemplateSetColumns.Also applies to: 95-97
base/src/main/resources/mappers/PlatformMapper.xml (2)
21-23: Standardize null-only checks for boolean flags in query fragment
Removed redundant!=''checks forisPublishandisDefault, leaving only!= null, which aligns with handling boolean fields.Also applies to: 48-50
103-105: Standardize null-only checks for boolean flags in update fragment
Updated<if>tests forisPublishandisDefaultto only test for non-null values inPlatformSetColumns, matching the query fragment changes.Also applies to: 130-132
base/src/main/resources/mappers/PageHistoryMapper.xml (2)
34-36: Remove redundant empty-string checks for flag fields in query fragment
The<if>conditions forisBody,isPage, andisDefaultnow only test for non-null, which is correct for boolean/flag fields.Also applies to: 46-48, 49-51
107-109: Remove redundant empty-string checks for flag fields in update fragment
The<if>tests forisBody,isPage, andisDefaulthave been simplified to only check for non-null values inPageHistorySetColumns.Also applies to: 119-124
base/src/main/resources/mappers/MaterialMapper.xml (2)
33-35: Simplify null-only checks for boolean flags in query fragment
The<if>conditions forisPublish,isOfficial,isDefault, andisTinyReservednow correctly only test for non-null values, removing the redundant!=''checks.Also applies to: 51-53, 54-56, 57-59
118-120: Simplify null-only checks for boolean flags in update fragment
Updated<if>tests forisPublish,isOfficial,isDefault, andisTinyReservedto only validate non-nullity inMaterialSetColumns, aligning with query fragment changes.Also applies to: 136-138, 139-141, 142-144
base/src/main/resources/mappers/PageMapper.xml (6)
29-31: SimplifyisBodycondition
Removing the!=''check is correct for a Boolean/flag field—testing onlyisBody != nullis sufficient and improves readability.
41-43: SimplifyisPagecondition
The empty‐string comparison was redundant for a Boolean-like field; retaining justisPage != nullstreamlines the SQL fragment without changing its behavior.
47-49: SimplifyisDefaultcondition
Dropping the string‐emptiness check is appropriate, sinceisDefaultrepresents a flag. The null check alone preserves correct filtering.
96-98: SimplifyisBodyupdate clause
In the<set>fragment, checking onlyisBody != nullsuffices for a Boolean field and makes the mapper more concise.
108-110: SimplifyisPageupdate clause
Removing the!=''portion is valid;isPage != nullalone correctly governs whether the column is included.
114-116: SimplifyisDefaultupdate clause
TestingisDefault != nullby itself is sufficient for a flag field and reduces unnecessary complexity.
English | 简体中文
PR
PR Checklist
Please check if your PR fulfills the following requirements:
PR Type
What kind of change does this PR introduce?
Background and solution
What is the current behavior?
Issue Number: N/A
What is the new behavior?
Does this PR introduce a breaking change?
Other information
Summary by CodeRabbit