base/src/main/java/com/tinyengine/it/service/platform/impl/PlatformHistoryServiceImpl.java (2)

80-84: 🛠️ Refactor suggestion

Return value check can silently swallow DB errors

deleteResult != 1 → CM008; ==1 → success.
If the record did not exist (0 affected rows) the caller gets generic “success” (line 78) which hides the fact that nothing was deleted. Consider distinguishing:

-if (deleteResult != 1) { ... }
+if (deleteResult == 0) {
+    return Result.failed(ExceptionEnum.DATA_NOT_FOUND);
+}

This yields clearer feedback to API consumers.

---

98-104: 🛠️ Refactor suggestion

Same silent-failure pattern on update

A 0-row update currently maps to CM008 (generic SQL fail).
Return a “not found” / “concurrent update” code instead so clients can react properly.

base/src/main/java/com/tinyengine/it/service/platform/impl/PlatformServiceImpl.java (1)

75-85: 🛠️ Refactor suggestion

Mark write operations @Transactional to ensure atomicity
deletePlatformById, updatePlatformById, and createPlatform each perform a read-then-write (or write-then-read) sequence.
Without @Transactional, a failure or concurrent update between the two statements can leave the service returning stale or inconsistent data.
Annotating the methods (or the whole class) with @Transactional(rollbackFor = Exception.class) will guarantee the read/write pair participates in one DB transaction.

 @Override
-public Result<Platform> deletePlatformById(Integer id) {
+@Transactional(rollbackFor = Exception.class)
+public Result<Platform> deletePlatformById(Integer id) {
   ...
 }

 @Override
-public Result<Platform> updatePlatformById(Platform platform) {
+@Transactional(rollbackFor = Exception.class)
+public Result<Platform> updatePlatformById(Platform platform) {
   ...
 }

 @Override
-public Result<Platform> createPlatform(Platform platform) {
+@Transactional(rollbackFor = Exception.class)
+public Result<Platform> createPlatform(Platform platform) {
   ...
 }

Also applies to: 94-104, 112-124

base/src/main/java/com/tinyengine/it/service/app/I18nEntryService.java (1)

35-97: 🛠️ Refactor suggestion

Large interface surface after extending IService

This interface now mixes:

1. Generic CRUD (already covered by IService<I18nEntry>).
2. High-level domain operations (batch upload, file parsing, formatting).

Consider splitting into two interfaces:

• I18nEntryCrudService extends IService<I18nEntry>
• I18nEntryDomainService with the higher-level methods

This adheres to the Interface Segregation Principle, eases testing, and clarifies responsibilities.

base/src/main/java/com/tinyengine/it/service/app/impl/UserServiceImpl.java (1)

84-97: 🛠️ Refactor suggestion

Add transaction boundaries for write operations.

updateUserById and createUser mutate state but are not annotated with @Transactional, so partial updates could escape rollback on exception.

@@
 @Override
-public Integer updateUserById(User user) {
-    return baseMapper.updateUserById(user);
+@Transactional(rollbackFor = Exception.class)
+public Integer updateUserById(User user) {
+    return baseMapper.updateUserById(user);
 }
@@
 @Override
-public Integer createUser(User user) {
-    return baseMapper.createUser(user);
+@Transactional(rollbackFor = Exception.class)
+public Integer createUser(User user) {
+    return baseMapper.createUser(user);
 }

base/src/main/java/com/tinyengine/it/service/material/impl/BlockServiceImpl.java (3)

330-336: ⚠️ Potential issue

Possible SQL-injection through manual OR-clause concatenation

labelsCondition is built via raw string interpolation:

String labelsCondition = block.stream()
    .map(name -> "label = '" + name + "'")
    .collect(Collectors.joining(" OR "));
wrapper.apply(labelsCondition);

Any illegal character in name (e.g. ' OR 1=1 --) will be injected verbatim.

Fix by using the fluent API instead of apply:

- String labelsCondition = block.stream()
-     .map(name -> "label = '" + name + "'")
-     .collect(Collectors.joining(" OR "));
- queryWrapper.and(w -> w.apply(labelsCondition));
+ queryWrapper.in("label", block);

---

590-598: 🛠️ Refactor suggestion

Redundant full fetch before paging – switch to selectCount

selectList(queryWrapper) is executed solely to obtain the record count, immediately followed by selectPage.
That doubles the query cost for large tables.

- List<Block> blocksList = baseMapper.selectList(queryWrapper);
- Page<Block> page = new Page<>(1, blocksList.size());
- return baseMapper.selectPage(page, queryWrapper);
+ long total = baseMapper.selectCount(queryWrapper);
+ Page<Block> page = new Page<>(1, total);
+ return baseMapper.selectPage(page, queryWrapper);

---

702-709: ⚠️ Potential issue

Null-pointer risk when blockDto.getGroups() is absent

blockDto.getGroups().stream() will throw if getGroups() returns null
(e.g. when a client omits the field).

Guard the call:

- List<Integer> groups = blockDto.getGroups().stream()
-     .map(BlockGroup::getId).collect(Collectors.toList());
+ List<Integer> groups = Optional.ofNullable(blockDto.getGroups())
+     .orElse(Collections.emptyList())
+     .stream()
+     .map(BlockGroup::getId)
+     .collect(Collectors.toList());

base/src/main/java/com/tinyengine/it/service/material/impl/MaterialServiceImpl.java (1)

76-82: ⚠️ Potential issue

Deleted record is fetched after deletion – returned payload will always be null

queryMaterialById is executed after the row has been removed, so the API will return data=null, while the caller probably expects the deleted object (your MaterialHistoryServiceImpl does it the right way).

-        int deleteResult = baseMapper.deleteMaterialById(id);
-        if (deleteResult != 1) {
-            return Result.failed(ExceptionEnum.CM008);
-        }
-        return this.queryMaterialById(id);
+        // fetch first so we can echo the deleted entity
+        Material material = baseMapper.queryMaterialById(id);
+        int deleteResult = baseMapper.deleteMaterialById(id);
+        if (deleteResult != 1) {
+            return Result.failed(ExceptionEnum.CM008);
+        }
+        return Result.success(material);

base/src/main/java/com/tinyengine/it/service/app/impl/PageServiceImpl.java (1)

177-185: ⚠️ Potential issue

Null-pointer risk when page / app is not found

pageInfo or the App returned by appMapper can be null. Calling methods on them without a guard (getApp(), getFramework()) will throw NullPointerException, turning a “not found” case into HTTP 500.

-        Page pageInfo = baseMapper.queryPageById(id);
+        Page pageInfo = baseMapper.queryPageById(id);
+        if (pageInfo == null) {
+            throw new ServiceException(ExceptionEnum.CM005.getResultCode(), "Page not found");
+        }
         String framework = appMapper.queryAppById(pageInfo.getApp()).getFramework();
-        if (framework.isEmpty()) {
+        if (framework == null || framework.isEmpty()) {
             throw new ServiceException(ExceptionEnum.CM312.getResultCode(), ExceptionEnum.CM312.getResultMsg());
         }

base/src/main/java/com/tinyengine/it/service/app/impl/AppExtensionServiceImpl.java (2)

82-88: ⚠️ Potential issue

Potential time-of-check / time-of-use race in delete flow.

Between queryAppExtensionById(id) and deleteAppExtensionById(id) another request could delete or modify the row, leading to a misleading success response (Result.success(appExtension)) even though the DELETE affected 0 rows.

Mitigate by:

1. Deleting first and checking rowsAffected; if 0 → CM009.
2. Executing both statements inside one transaction (see previous comment).

---

116-124: 🛠️ Refactor suggestion

Duplicate-check and insert should be atomic.

queryAppExtensionByCondition followed by createAppExtension is vulnerable to race conditions. Use a DB unique constraint and rely on exception handling, or enclose both operations in a transaction with a SELECT … FOR UPDATE.

base/src/main/java/com/tinyengine/it/service/material/impl/BlockGroupServiceImpl.java (1)

191-208: 🛠️ Refactor suggestion

N+1 query pattern – fetch groups in bulk instead of per-ID loop.

Looping over ids and invoking queryBlockGroupAndBlockById one-by-one incurs a DB round-trip per element. Replace with a single mapper method that accepts a collection:

-        for (int blockgroupId : ids) {
-            blockGroup = baseMapper.queryBlockGroupAndBlockById(blockgroupId, blockCreatedBy, groupCreatedBy);
-            blockGroupsListResult.add(blockGroup);
-        }
+        blockGroupsListResult =
+            baseMapper.queryBlockGroupAndBlockByIds(ids, blockCreatedBy, groupCreatedBy);

This will significantly improve latency when ids.size() is large.

base/src/main/java/com/tinyengine/it/service/material/MaterialService.java (2)

26-26: Same note as TaskRecordService: duplicated CRUD after IService

IService<Material> already offers generic CRUD methods.

---

40-41: @Param removal can break mapper XML – verify build flags

See earlier comment in TaskRecordService.

Also applies to: 56-57

base/src/main/java/com/tinyengine/it/service/app/PageService.java (2)

28-28: Duplicated CRUD after IService

The interface now exposes both getById (via IService) and custom queryPageById. Harmonise or remove duplicates to avoid API confusion.

---

43-44: Potential MyBatis parameter-name mismatch

Dropping @Param("id") bears the same runtime risk described earlier.

Also applies to: 59-60

base/src/main/java/com/tinyengine/it/service/material/MaterialHistoryService.java (2)

26-26: Redundant custom CRUD after adopting IService

Same rationale as previous service interfaces.

---

40-41: Verify MyBatis XML after @Param removal

Same concern as noted for the other services.

Also applies to: 56-57

base/src/main/java/com/tinyengine/it/service/platform/TenantService.java (1)

25-55: Extending IService but still redefining CRUD-like APIs – consider consolidation

Now that the interface inherits MyBatis-Plus IService<Tenant>, common methods such as getById, removeById, updateById, save, and list are already available.
Keeping custom equivalents (findTenantById, deleteTenantById, etc.) can confuse clients and inflate maintenance cost.

If no domain-specific behaviour is added, consider:

-public interface TenantService extends IService<Tenant> {
-    ...
-    Tenant findTenantById(Integer id);
-    ...
-    Integer deleteTenantById(Integer id);
-    ...
-}
+public interface TenantService extends IService<Tenant> {
+    // Add only domain-specific queries that are NOT covered by IService
+}

Otherwise, document clearly why both variants coexist.

base/src/main/java/com/tinyengine/it/service/platform/PlatformService.java (1)

26-56: Duplicate CRUD surface after inheriting IService<Platform>

Same observation as in TenantService: queryPlatformById, deletePlatformById, etc., overlap with IService defaults, with extra wrapping into Result<T>.
Decide either to:

1. Fully rely on IService and drop custom methods, or
2. Keep the richer Result<T> contract but remove/alias the redundant reads (queryPlatformById vs getById) to avoid two ways of doing the same thing.

Aligning method names will ease onboarding and reduce cognitive load.

base/src/main/java/com/tinyengine/it/service/platform/PlatformHistoryService.java (1)

26-56: Interface inherits IService but still exposes CRUD methods

As with the other services, decide whether these custom methods add value over IService defaults; otherwise trim for clarity or rename to emphasise domain semantics (e.g., archiveHistory(...) vs create).

base/src/main/java/com/tinyengine/it/service/platform/impl/TenantServiceImpl.java (2)

52-54: baseMapper.queryTenantById duplicates getById

Since ServiceImpl already offers getById(id), consider delegating to it or removing the wrapper unless extra logic is injected.

-return baseMapper.queryTenantById(id);
+return this.getById(id);

---

85-98: Consider leveraging saveOrUpdate from ServiceImpl

Manual baseMapper.updateTenantById / createTenant pairs can be replaced with the framework’s saveOrUpdate(tenant), reducing boilerplate and centralising optimistic-lock handling (if enabled).

base/src/main/java/com/tinyengine/it/service/platform/impl/PlatformServiceImpl.java (2)

43-66: Prefer the built-in CRUD helpers to cut duplication
queryAllPlatform, queryPlatformById, and queryPlatformByCondition still delegate straight to baseMapper.
If these methods merely wrap standard list(), getById(id) or a simple lambda query, you can delete them altogether and expose the inherited list/getById from ServiceImpl.
This keeps the service layer thinner and avoids maintaining duplicate SQL in PlatformMapper.

-@Override
-public List<Platform> queryAllPlatform() {
-    return baseMapper.queryAllPlatform();
-}
+// Callers can now just use platformService.list();

---

115-119: Stricter name validation
platform.getName().isEmpty() treats strings containing only whitespace as valid.
Switching to StringUtils.hasText(platform.getName()) (Spring) or StringUtils.isNotBlank (Apache Commons) closes that gap.

-if (platform.getName() == null || platform.getName().isEmpty()) {
+if (!StringUtils.hasText(platform.getName())) {
     return Result.failed(ExceptionEnum.CM002);
 }

app/src/main/java/com/tinyengine/it/config/filter/WebConfig.java (1)

33-49: Nit: typo in variable name

crosDomainList → corsDomainList to keep naming consistent with the CORS acronym.

base/src/main/java/com/tinyengine/it/service/material/ComponentLibraryService.java (1)

26-72: Redundant CRUD methods after adopting IService

By extending IService<ComponentLibrary> you already inherit a full CRUD API (getById, removeById, updateById, save, list, etc.).
Keeping additional methods (queryComponentLibraryById, deleteComponentLibraryById, updateComponentLibraryById, createComponentLibrary) that merely wrap the same semantics introduces duplication and cognitive overhead.

If the intent is to add domain-specific behaviour (e.g. wrapping the result in Result<>), consider:

1. Renaming the wrapper methods to clarify the added value (e.g. getWithValidation).
2. Or drop them and let callers use the inherited MyBatis-Plus methods directly.

Cleaning this up will shrink the service interface surface and make the codebase more consistent with other modules that rely solely on IService.

base/src/main/java/com/tinyengine/it/service/app/UserService.java (2)

25-56: Consolidate CRUD to the inherited IService API

Same observation as for ComponentLibraryService: queryUserById, deleteUserById, etc. overlap with getById, removeById, list() provided by IService<User>.

Unless these methods deliver extra behaviour (e.g. audit, validation, Result<> wrapping), consider deleting them and relying on the default API to avoid bloat and maintenance friction.

---

31-39: Naming consistency: plural vs singular

Method queryAllUser() mixes plural semantics with a singular noun.
Recommend renaming to queryAllUsers() (or simply listUsers() if retained).

base/src/main/java/com/tinyengine/it/service/material/ComponentService.java (2)

32-70: Consider eliminating duplicated find*/delete* methods

After extending IService<Component> the interface already exposes:

• getById(id) ➜ findComponentById
• removeById(id) ➜ deleteComponentById
• list() ➜ findAllComponent
• updateById(entity) ➜ updateComponentById
• save(entity) ➜ createComponent

Unless you need the custom return types (Result<>) or additional processing, drop the duplicates to keep the contract minimal.

---

62-63: Return type semantics

deleteComponentById returns Integer, presumably the affected row count.
MyBatis-Plus’s removeById returns boolean, which is clearer for consumers.
If you keep the custom method, consider switching to boolean to express intent unambiguously.

base/src/main/java/com/tinyengine/it/service/material/TaskRecordService.java (1)

28-36: queryTaskRecordById duplicates getById

Given the new IService<TaskRecord> parent, getById(id) is available out-of-the-box.
Please remove or repurpose queryTaskRecordById to avoid two ways of doing the same thing.

base/src/main/java/com/tinyengine/it/service/app/I18nEntryService.java (1)

35-50: Camel-case inconsistency & typo

Method readFilesAndbulkCreate has a lowercase “b” in “bulk”.
Recommend renaming to readFilesAndBulkCreate for standard camel-case formatting.

base/src/main/java/com/tinyengine/it/service/app/I18nLangService.java (1)

15-26: Redundant CRUD declarations now that IService is inherited.

IService<I18nLang> already exposes list(), getById(), removeById(), save(), updateById() …
Keeping custom aliases (queryAllI18nLang, deleteI18nLangById …) creates two parallel APIs for the same thing and inflates the surface area.

Consider:

1. Drop the duplicated methods and rely on the generic ones; or
2. Keep the methods but mark them @Deprecated and delegate to generic calls.

This will reduce maintenance cost and confusion for future contributors.

base/src/main/java/com/tinyengine/it/service/app/AppExtensionService.java (1)

15-27: Same duplication concern as above – streamline against IService.

The interface now inherits full CRUD; reevaluate whether findAppExtensionById, deleteAppExtensionById, etc. need to stay. If they provide extra behaviour (e.g. wrapping Result<>), document the difference clearly to avoid accidental misuse.

base/src/main/java/com/tinyengine/it/service/app/AppService.java (1)

29-29: Avoid redundant CRUD wrappers after inheriting IService

IService<App> already offers generic CRUD operations (list(), getById(), removeById(), etc.).
Keeping bespoke equivalents (queryAllApp, queryAppById, deleteAppById, …) inflates the API surface and sends mixed signals to callers.

Consider either

-interface AppService extends IService<App> {
+interface AppService extends IService<App> {
+    // keep only domain-specific methods …

or drop the IService inheritance if you need fully customized semantics.

base/src/main/java/com/tinyengine/it/service/material/BlockService.java (1)

34-34: Duplicate CRUD contracts

Extending IService<Block> while still declaring queryBlockById, deleteBlockById, etc., repeats functionality and may confuse clients (which one to call?).

If domain-specific wrapping is required, rename the methods (e.g. fetchDtoById) to communicate the added value, otherwise rely on IService alone.

base/src/main/java/com/tinyengine/it/service/app/DatasourceService.java (1)

26-26: Consistency vs. verbosity

Same observation: inheriting IService<Datasource> plus hand-rolled CRUD style methods increases maintenance overhead. Evaluate whether the custom wrappers are still justified.

base/src/main/java/com/tinyengine/it/service/app/PageTemplateService.java (1)

26-26: Potential overlap with IService<PageTemplate>

IService already exposes getById, removeByIds, etc. Reconsider keeping queryPageTemplateById, deletePageTemplateByIds, … to avoid redundancy.

base/src/main/java/com/tinyengine/it/service/material/BusinessCategoryService.java (1)

25-25: Redundant CRUD methods

Same duplication concern: IService<BusinessCategory> already supplies CRUD; extra wrappers should have clear added value or be removed.

base/src/main/java/com/tinyengine/it/service/app/TaskRecordService.java (1)

25-25: Consider pruning duplicate CRUD declarations after extending IService

By inheriting from IService<TaskRecord> you already get getById, removeById, save, etc.
Keeping home-grown equivalents (queryTaskRecordById, deleteTaskRecordById, …) bloats the API surface and may confuse callers about which variant to use.

base/src/main/java/com/tinyengine/it/service/app/impl/AppServiceImpl.java (1)

94-100: Custom queryAppById duplicates ServiceImpl#getById

The bespoke method adds minimal value over the built-in getById. Consider delegating to or removing this wrapper to keep the interface lean.

base/src/main/java/com/tinyengine/it/service/material/BlockHistoryService.java (1)

15-26: Duplicate CRUD surface after introducing IService

Now that the interface extends IService<BlockHistory>, generic CRUD helpers (getById, list, removeById, save …) come for free. Keeping bespoke counterparts (findBlockHistoryById, deleteBlockHistoryById, etc.) bloats the API surface and invites inconsistent use.

Consider dropping the hand-rolled methods (or delegating them to the inherited ones) to keep the service lean and consistent.

base/src/main/java/com/tinyengine/it/service/material/impl/ComponentServiceImpl.java (2)

55-56: ServiceImpl adopted — leverage its built-ins

Extending ServiceImpl<ComponentMapper, Component> already provides getById, list, saveBatch, saveOrUpdateBatch, etc. Most of the wrapper methods below re-expose mapper calls 1-for-1, defeating the purpose and adding maintenance overhead.

If no extra domain logic is injected, prefer the out-of-the-box methods or add thin adapters that simply call super helpers rather than raw baseMapper calls.

---

69-83: Missed opportunity to replace bespoke queries with MP wrappers

queryAllComponent, queryComponentById and queryComponentByCondition look like straight-through SQL pores.
Unless they rely on custom joins/filters, they could be replaced with:

return list();                // all
return getById(id);           // single
return lambdaQuery()
         .setEntity(component) // or build conditions explicitly
         .list();              // conditional

This reduces mapper code and aligns with the new MyBatis-Plus direction.

base/src/main/java/com/tinyengine/it/service/app/impl/PageHistoryServiceImpl.java (2)

48-60: Redundant wrappers around simple CRUD

With ServiceImpl<PageHistoryMapper, PageHistory> you already have list(), getById(), etc.
findAllPageHistory and findPageHistoryById presently just proxy to the mapper. Unless they encapsulate complex SQL, consider deleting them or delegating to inherited helpers to avoid duplicating the API.

---

81-82: Custom delete mirrors removeById

return baseMapper.deletePageHistoryById(id);

If this is a plain PK delete, boolean removeById(id) from ServiceImpl does the job and returns success status. Swapping would simplify code and testing.

base/src/main/java/com/tinyengine/it/service/app/impl/DatasourceServiceImpl.java (2)

35-45: ServiceImpl migration not fully utilised

Most service methods still fall back to mapper calls (queryDatasourceById, createDatasource, …). Evaluate replacing straightforward CRUD with the generic helpers provided by ServiceImpl to minimise boilerplate and mapper surface.

---

100-101: Prefer save() over custom createDatasource if no special SQL is needed

If createDatasource performs a simple insert, the built-in save(datasource) (or saveOrUpdate) would remove the need for a mapper method entirely and benefit from MP features such as automatic field filling.

base/src/main/java/com/tinyengine/it/service/app/impl/I18nLangServiceImpl.java (1)

33-42: Prefer MyBatis-Plus default CRUD over 1-to-1 passthrough methods

Now that the class extends ServiceImpl, the framework already provides

list()
getById(id)
save(entity)
updateById(entity)
removeById(id)

and other helpers.
queryAllI18nLang, queryI18nLangById, etc. are simple passthroughs to custom mapper methods that replicate this behaviour and add maintenance surface.

If no extra SQL is really needed, consider deleting the custom mapper methods and, in the service, delegating to the built-ins instead.
This will:

• reduce boilerplate
• keep the codebase consistent with MyBatis-Plus idioms
• ease unit-testing / mocking

base/src/main/java/com/tinyengine/it/service/material/impl/BlockHistoryServiceImpl.java (1)

33-42: Same CRUD duplication issue as above

findAllBlockHistory() is functionally identical to list() that you already inherit from ServiceImpl.
Re-evaluate whether the custom queryAllBlockHistory mapper method is still justified.

base/src/main/java/com/tinyengine/it/service/material/impl/ComponentLibraryServiceImpl.java (1)

35-44: Reuse inherited CRUD where possible

queryAllComponentLibrary() is equivalent to list().
Unless custom SQL is essential, migrate to the built-in API and delete the extra mapper method to keep the service lean.

base/src/main/java/com/tinyengine/it/service/app/impl/PageTemplateServiceImpl.java (1)

52-57: Potential elimination of duplicated mapper calls

Within the name == null || name.isEmpty() branch you already fetch all
page templates once.
Right after the branch you perform a second fetch based on name.
Consider restructuring the method to make exactly one mapper call:

List<PageTemplate> pageTemplates = StringUtils.isBlank(name)
        ? baseMapper.queryAllPageTemplate(type)
        : baseMapper.queryPageTemplateByName(name, type);
return Result.success(pageTemplates);

Minor, but saves an allocation and keeps the method concise.

base/src/main/java/com/tinyengine/it/service/material/impl/MaterialServiceImpl.java (1)

108-112: Minor: use forEach for side-effects instead of map

The stream pipeline here is only used for its side-effects; using map is semantically misleading and allocates an unused List<Integer>. Replace with forEach to express intent.

-i18nEntriesList.stream().map(entry -> baseMapper.createMaterial(entry)).collect(Collectors.toList());
+i18nEntriesList.forEach(entry -> baseMapper.createMaterial(entry));

base/src/main/java/com/tinyengine/it/service/app/impl/I18nEntryServiceImpl.java (1)

153-156: Replace stream().map(..).collect(..) used only for side-effects

Using map here hides the intent and creates an unnecessary intermediate list. A simple forEach is clearer and avoids the extra allocation.

-i18nEntriesList.stream().map(entry -> baseMapper.createI18nEntry(entry)).collect(Collectors.toList());
+i18nEntriesList.forEach(baseMapper::createI18nEntry);

Apply the same change in the bulkCreate path below.

Also applies to: 199-201

base/src/main/java/com/tinyengine/it/service/app/impl/TaskRecordServiceImpl.java (1)

41-41: Leverage built-in MyBatis-Plus helpers instead of hand-rolled mapper calls.

ServiceImpl already exposes list() which returns all rows.
Keeping both queryAllTaskRecord() and list() creates API duplication.

Example replacement:

-    public List<TaskRecord> queryAllTaskRecord() {
-        return baseMapper.queryAllTaskRecord();
-    }
+    public List<TaskRecord> queryAllTaskRecord() {
+        return list();
+    }

base/src/main/java/com/tinyengine/it/service/material/impl/BlockGroupServiceImpl.java (2)

63-64: queryAllBlockGroup() duplicates list() from ServiceImpl.

Unless you require custom SQL, prefer list() to reduce mapper code and improve maintainability.

---

211-211: Avoid full-table scan when no filter supplied.

Calling queryAllBlockGroupAndBlock with no ids and no appId can explode in large installations.
Require at least one filtering parameter or enforce pagination to protect the database.

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro