ruanwenjun opened a new issue, #18249:
URL: https://github.com/apache/dolphinscheduler/issues/18249
## Description
`dolphinscheduler-dao/CLAUDE.md` already documents the intent that
upper-layer modules should not call `dao.mapper.*` directly; they should
go through `dao.repository.*` (Dao), which wraps the Mapper. master /
worker / alert already have zero direct `dao.mapper` imports, so the
boundary is held in those modules.
However, the boundary is **not** held in `dolphinscheduler-api`, and is
partially leaking in `dolphinscheduler-service` and `dolphinscheduler-tools`.
| Module | Files importing `dao.mapper.*` |
| ---------------------------- | ------------------------------ |
| `dolphinscheduler-api` | 51 |
| `dolphinscheduler-service` | 3 (`ProcessServiceImpl`,
`CommandServiceImpl`, `CuringParamsServiceImpl`) |
| `dolphinscheduler-tools` | 2 (`MigrateResourceService`,
`MigrateLineageService`) |
| `dolphinscheduler-master` | 0 |
| `dolphinscheduler-worker` | 0 |
| `dolphinscheduler-alert` | 0 |
In addition, the following Mappers currently have **no corresponding Dao
at all**, so consumers have no choice but to depend on the Mapper:
`AccessTokenMapper`, `AlertMapper`, `AlertGroupMapper`,
`AlertPluginInstanceMapper`, `AlertSendStatusMapper`, `AuditLogMapper`,
`ClusterMapper`, `DataSourceMapper`, `DataSourceUserMapper`,
`EnvironmentWorkerGroupRelationMapper`, `ErrorCommandMapper`,
`FavTaskMapper`, `K8sNamespaceMapper`, `K8sNamespaceUserMapper`,
`PluginDefineMapper`, `ProjectParameterMapper`, `ProjectPreferenceMapper`,
`ProjectUserMapper`, `QueueMapper`, `RelationSubWorkflowMapper`,
`WorkflowInstanceRelationMapper`, `WorkflowTaskRelationMapper`.
## Goal
Make the boundary hold uniformly:
1. Every Mapper used from the upper layers has a corresponding Dao in
`dao.repository`.
2. Every upper-layer file (api / service / tools) replaces its
`dao.mapper.*` import with the Dao.
## Plan
One Mapper per PR, matching the cadence already used by the
`ProjectMapper` and `WorkflowDefinitionMapper` migrations:
1. Pick a Mapper referenced from `api` / `service` / `tools`.
2. Ensure the Dao exposes every method the upper layer needs (add
missing methods; adapt signatures where the Dao chooses a richer
return type such as `Optional<T>`).
3. Replace every direct Mapper reference, including the corresponding
tests (migrate mocks from `WorkflowDefinitionMapper` to
`WorkflowDefinitionDao`, wrap `queryByCode` stubs in `Optional.of` /
`Optional.empty`, etc.).
4. Keep behavior 1:1 (e.g. `Optional<T>.orElse(null)` when the Mapper
returned a bare nullable).
This issue is the umbrella; each Mapper migration is a separate PR
linking back here.
### Progress
- [x] `ProjectMapper` → `ProjectDao`
- [x] `WorkflowDefinitionMapper` → `WorkflowDefinitionDao` (PR pending)
- [ ] Remaining Mappers per the lists above
- [ ] `ProcessServiceImpl` in `dolphinscheduler-service` and the
`tools` direct Mapper users
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail:
[email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
