3.3 KiB
Freelance + IT-OPS 插件技术评审
1. 实体数量合理性
freelance 8 实体不过重。 现有插件代码证实:WASM Guest 实现极其轻量(CRM 仅 30 行 Rust,只实现 Guest trait 的 3 个空方法),所有业务逻辑由 Host 侧的 PluginDataService + DynamicTableManager 通用处理。WASM 二进制不含 ORM/业务逻辑,因此 8 实体与 5 实体的 Guest 代码几乎无差别。manifest 解析(manifest.rs)和建表 DDL 均按 entity 循环处理,无硬上限。
真正的复杂度在前端页面数量和表间关联(quote/quote_line 父子关系),需确保 plugin.toml 的 relations 声明完整。
2. 跨插件引用性能
itops 4 个实体都引用 freelance.client 是合理的。代码显示跨插件引用走的是同一数据库内 SQL 查询(resolve_cross_plugin_entity 解析出 plugin_erp-freelance_client 表名后直接 JOIN/EXISTS),没有 RPC 调用或跨服务开销。列表查询时 resolve_labels 会批量解析 UUID→label,也是单次 IN 查询。
风险点:4 个实体同时查询时各做一次跨插件表 JOIN,并发高时需关注连接池。但每个查询都是标准 SQL,PostgreSQL 处理无压力。建议 itops 的 client_id 字段设 filterable = true 使其走 generated column 索引。
3. select 枚举字段声明
现有代码已完全支持。CRM plugin.toml 中有大量实例:
[[schema.entities.fields]]
name = "status"
field_type = "string"
ui_widget = "select"
filterable = true
options = [
{ label = "草稿", value = "draft" },
{ label = "已审核", value = "approved" },
]
字段类型声明为 string,枚举值通过 options 数组提供(label + value)。解析侧 PluginField.options: Option<Vec<serde_json::Value>> 兼容此格式。filterable = true 会自动创建 generated column + 索引以加速过滤查询。
4. WASM 体积预估
实测数据:
- CRM (5 实体): 22 KB (raw), 22.8 KB (component)
- Inventory (6 实体): 22 KB (raw)
- test-sample (含 Host API 回调测试): 109 KB
freelance (8 实体) Guest 代码同样只有 Guest trait 空实现,预估 22-23 KB。体积与实体数量无关,取决于引入的 Host API 回调复杂度。itops 更小(4 实体),预估 22 KB。两者合计约 45 KB,对运行时内存和加载速度无影响。
5. 技术风险
-
quote/quote_line 父子关系:quote_line 引用 quote 是同插件内引用,需在 plugin.toml 中声明
ref_entity = "quote"+relations的on_delete = "cascade"。父实体删除时需级联软删除子记录 -- 当前validate_ref_entities只做引用存在性校验,级联软删除需确认DynamicTableManager是否支持(需检查on_delete: cascade在 list/create 流程中的实现)。 -
itops 依赖声明:
metadata.dependencies = ["erp-plugin-freelance"],但ref_plugin字段应填 manifest ID(即"erp-plugin-freelance")。需确认 manifest ID 与 Cargo crate name 的命名映射一致。 -
freelance.client 需标记
is_public = true:否则 itops 的跨插件ref_plugin查询会找不到目标实体。CRM 的 customer 已正确标记。 -
权限码数量:freelance 16 个权限码、itops 8 个,均在合理范围。注意每个实体必须声明
.list+.manage,缺.list会导致列表页 403。