122 lines
7.2 KiB
Markdown
122 lines
7.2 KiB
Markdown
# pig-farm-controller - Technical Specification
|
||
|
||
**Author:** 主人
|
||
**Date:** 2025年11月1日星期六
|
||
**Project Level:** 0
|
||
**Project Type:** software
|
||
**Development Context:** Brownfield Level 0 - Single Atomic Change: Implementing usage checks before deleting devices, device templates, and regional controllers to prevent data inconsistency and errors.
|
||
|
||
---
|
||
|
||
## Source Tree Structure
|
||
|
||
```
|
||
# 涉及文件（初步判断，**请在实际开发中根据代码结构进行确认**）：
|
||
# internal/app/controller/device_controller.go (处理设备删除请求)
|
||
# internal/app/controller/device_template_controller.go (处理设备模板删除请求)
|
||
# internal/app/controller/region_controller.go (处理区域主控删除请求)
|
||
# internal/app/service/device_service.go (设备业务逻辑，可能包含删除操作)
|
||
# internal/app/service/device_template_service.go (设备模板业务逻辑，可能包含删除操作)
|
||
# internal/app/service/region_service.go (区域主控业务逻辑，可能包含删除操作)
|
||
# internal/infra/repository/device_repository.go (设备数据访问层)
|
||
# internal/infra/repository/device_template_repository.go (设备模板数据访问层)
|
||
# internal/infra/repository/region_repository.go (区域主控数据访问层)
|
||
```
|
||
|
||
---
|
||
|
||
## Technical Approach
|
||
|
||
在删除设备、设备模板和区域主控的 API 接口和业务逻辑层中，引入使用状态检查。
|
||
1. **识别依赖关系：** 确定哪些实体依赖于设备、设备模板和区域主控。例如，设备可能依赖于设备模板，区域主控可能包含多个设备。
|
||
2. **实现检查逻辑：** 在执行删除操作之前，查询相关数据表，检查待删除实体是否被其他实体引用。
|
||
3. **返回错误信息：：** 如果发现实体正在被使用，则返回明确的错误信息，阻止删除操作。
|
||
4. **事务性操作：** 确保检查和删除操作的原子性，防止并发问题。
|
||
|
||
---
|
||
|
||
## Implementation Stack
|
||
|
||
* **Go**: 核心编程语言
|
||
* **GORM**: ORM 框架，用于数据库操作
|
||
* **Echo**: Web 框架，用于处理 HTTP 请求
|
||
* **PostgreSQL with TimescaleDB**: 数据库 (通过 TimescaleDB 进行时序表加强)
|
||
|
||
---
|
||
|
||
## Technical Details
|
||
|
||
1. **设备删除检查：**
|
||
* 在 `internal/app/service/device_service.go` 的 `DeleteDevice` 方法中实现。
|
||
* **依赖关系识别：**
|
||
* **任务关联：** 检查 `task` 表中是否存在 `device_id` 关联的活跃任务（例如 `running` 或 `pending` 状态）。
|
||
* **数据点（历史记录）：** 检查 `data_point` 表或其他相关历史数据表中是否存在与该设备关联的数据。**特别注意 TimescaleDB 的时序表特性，确保查询效率。**
|
||
* **告警/事件：** 检查 `alert` 或 `event` 表中是否存在与该设备相关的未关闭记录。
|
||
* **配置引用：** 检查其他配置表（例如 `schedule` 表的特定设备配置）是否引用该设备。
|
||
* **检查逻辑：**
|
||
* 通过数据库查询或调用其他服务接口，检查上述依赖。
|
||
* **错误处理：** 如果发现任何依赖，返回自定义业务错误码（例如 `ERR_DEVICE_IN_USE`）和描述性错误信息，通过 API 返回 `409 Conflict` 状态码。**确保错误信息清晰、具体，并能指导用户采取下一步行动。**
|
||
|
||
2. **设备模板删除检查：**
|
||
* 在 `internal/app/service/device_template_service.go` 的 `DeleteDeviceTemplate` 方法中实现。
|
||
* **依赖关系识别：**
|
||
* **设备引用：** 检查 `device` 表中是否存在 `template_id` 关联的设备实例。
|
||
* **历史配置：** 检查是否有历史配置或归档数据仍引用此模板。
|
||
* **检查逻辑：**
|
||
* 查询 `device` 表，计算使用该模板的设备数量。
|
||
* **错误处理：** 如果存在设备正在使用该模板，返回业务错误码（例如 `ERR_TEMPLATE_IN_USE`）和错误信息，通过 API 返回 `409 Conflict` 状态码。**错误信息应明确指出哪些设备正在使用该模板。**
|
||
|
||
3. **区域主控删除检查：**
|
||
* 在 `internal/app/service/region_service.go` 的 `DeleteRegion` 方法中实现。
|
||
* **依赖关系识别：**
|
||
* **设备关联：** 检查 `device` 表中是否存在 `region_id` 关联的设备实例。
|
||
* **子区域嵌套：** 检查 `region` 表中是否存在 `parent_region_id` 关联的子区域。
|
||
* **用户/权限关联：** 检查 `user_region_access` 或类似权限表中是否存在与该区域关联的访问权限配置。
|
||
* **检查逻辑：**
|
||
* 查询 `device` 表和 `region` 表，计算关联的设备和子区域数量。
|
||
* **错误处理：** 如果存在关联实体，返回业务错误码（例如 `ERR_REGION_IN_USE`）和错误信息，通过 API 返回 `409 Conflict` 状态码。**错误信息应明确指出哪些设备或子区域正在使用该区域主控。**
|
||
|
||
4. **错误处理统一化：**
|
||
* 定义一个中心化的错误处理机制，例如使用一个 `errors` 包来封装自定义错误类型（`UsageConflictError`）和错误码。
|
||
* API 层 (`internal/app/controller`) 捕获这些业务错误，并将其转换为适当的 HTTP 响应，例如 `http.StatusConflict (409)`。
|
||
* 确保错误信息清晰、用户友好，并可供前端进行翻译或展示。**错误信息应尽可能提供解决问题的建议。**
|
||
|
||
---
|
||
|
||
## Development Setup
|
||
|
||
无需特殊开发环境设置，遵循现有项目 Go 开发规范。
|
||
|
||
---
|
||
|
||
## Implementation Guide
|
||
|
||
1. **定位删除逻辑：** 找到 `device_service.go`、`device_template_service.go` 和 `region_service.go` 中对应的删除方法。
|
||
2. **添加依赖检查函数：** 在每个删除方法内部或其调用的辅助函数中，实现检查逻辑。
|
||
3. **集成错误处理：** 在检查失败时，返回自定义错误或使用现有错误处理机制。
|
||
4. **编写单元测试：** 为新的检查逻辑编写单元测试，覆盖删除成功和删除失败（因被使用）的场景。
|
||
5. **编写集成测试：** 编写集成测试，模拟删除操作，验证端到端的行为。
|
||
|
||
---
|
||
|
||
## Testing Approach
|
||
|
||
* **单元测试：**
|
||
* 针对 `device_service.go`、`device_template_service.go` 和 `region_service.go` 中的检查逻辑编写单元测试。
|
||
* 模拟有依赖和无依赖的场景，验证删除操作的行为。
|
||
* **集成测试：**
|
||
* 编写 API 集成测试，模拟删除设备、设备模板和区域主控的请求。
|
||
* 测试在有依赖和无依赖情况下的 API 响应（HTTP 状态码和错误信息）。
|
||
* **手动测试：**
|
||
* 在开发环境中，手动创建依赖关系，然后尝试删除被使用的实体，验证系统行为。
|
||
* 手动创建无依赖的实体，验证可以正常删除。
|
||
|
||
---
|
||
|
||
## Deployment Strategy
|
||
|
||
* **代码审查：** 提交代码进行严格的代码审查。
|
||
* **CI/CD 流程：** 通过现有的 CI/CD 流程进行自动化测试和部署。
|
||
* **灰度发布：** 如果可能，采用灰度发布策略，逐步将更改部署到生产环境，监控系统行为。
|
||
* **回滚计划：** 制定详细且经过测试的回滚计划，以防出现意外问题，**确保在紧急情况下能够快速恢复。**
|