Elsa Persistence vNext 开发任务全景解析:从 Provider 无关存储清单到工作流运行时评估的八阶段路线图
后端工作流自动化流程编排低代码【免费下载链接】elsa-coreThe Workflow Engine for .NET项目地址https://gitcode.com/gh_mirrors/el/elsa-core点击查看免费下载本文基于 Elsa Core 仓库中 specs/011-persistence-vnext/tasks.md 的完整任务清单T001–T054结合同目录的 spec.md、roadmap.md 与src/modules/Elsa.Persistence.VNext*系列源码系统梳理 Elsa Persistence vNext 这一Provider 无关、模块零迁移、文档存储为默认、物理化按策略可选的新一代持久化架构的分阶段落地计划、当前实现状态、验收标准与源码佐证。读完本文你可以掌握该架构从存储清单Manifest→ 规划器Planner→ 渲染器Renderer→ 物化Materialization→ 文档存储 → 运行时实体 → 物理化策略的完整开发闭环并据此判断各阶段任务的依赖关系与剩余工作。一、任务清单的定位一份可执行、可追踪的八阶段开发计划specs/011-persistence-vnext/tasks.md 是 Persistence vNext 特性的执行任务清单它把 spec.md 中的用户故事与功能需求FR-001 到 FR-018翻译为 8 个阶段S1–S8、共 54 个可勾选的任务项T001–T054并明确标注每项的完成状态[x]已完成 /[ ]待办。从任务结构可以清晰看到整条架构主线S1 是地基先建立 Provider 中立的存储描述符与规划器让一次声明、多 Provider 复用成为可能S2–S4 是存储能力依次打通 SQLite可移植文档存储 MVP、SQL Server / PostgreSQL关系型文档 Provider、MongoDB原生文档 ProviderS5 是接入 Elsa把 vNext 持久化接入 Elsa 特性系统并完成第一个真实模块Secrets的迁移S6–S7 是能力扩展运行时自定义实体Runtime-Defined Entities与按策略的物理化优化PhysicalizationS8 是收尾评估对工作流运行时热路径做基准测试与 go/no-go 决策形成生产化硬化结论。每个任务项都对应 roadmap.md 中一个或多个 GitHub issue#7670–#7677是典型的规范 → 计划 → 执行 → 验证 → 合并闭环管理方式。二、S1 — Core Manifest And Planner FoundationsProvider 无关存储声明的根基S1 的目标roadmap.md 原文模块只需声明一次 Provider 无关的存储意图关系型规划器与文档规划器即可消费同一份 Manifest。任务项包括 T001–T011其中 T008打开/更新 S1 PR与 T010、T011合并 PR、关闭 issue仍待办核心编码工作已全部完成。2.1 核心描述符模型T001T001 Add provider-neutral storage descriptors 已完成的产物集中在 src/modules/Elsa.Persistence.VNext/Models 目录五个核心类型构成存储声明的词汇表PersistenceSchema整份存储模式的根包含Name、Version、Tables与StorageUnits见 PersistenceSchema.csPersistenceStorageUnitProvider 中立的持久化单元声明Name、Namespace、Fields、Key主键与Indexes见 PersistenceStorageUnit.csPersistenceField/PersistenceIndex/PersistencePrimaryKey分别描述字段、查询索引与主键约束PersistenceColumn/PersistenceColumnType关系型列与列类型的抽象描述。这正是 spec.md 中Key Entities所定义的 Persistence Manifest、Storage Unit、Field、Index 等概念在代码中的直接落地。2.2 规划器与渲染器契约T002–T004任务 T002关系型规划器 SQLite 渲染器、T003SQL Server 渲染器、T004文档规划器围绕四份契约接口展开见 src/modules/Elsa.Persistence.VNext/ContractsIPersistenceSchemaPlanner把 Manifest 规划为 Provider 家族的执行计划IPersistenceSchemaRenderer把计划渲染为具体 DDLIPersistenceSchemaProvider提供/注册 Schema 来源IPersistenceSchemaMigrator执行迁移见下文 Schema History。具体实现上关系型一侧有 RelationalSchemaPlanner.cs产出RelationalSchemaPlan含RelationalTable、RelationalColumn、RelationalIndex、RelationalPrimaryKey文档一侧有 DocumentDatabasePlanner.cs产出DocumentDatabasePlan含DocumentCollection、DocumentField、DocumentIndexSQLite 与 SQL Server 分别提供SqliteSchemaSqlRenderer、SqlServerSchemaSqlRenderer作为 DDL 渲染器。同一份 Manifest 同时产出关系型与文档型计划的验收标准正是 spec.md 中 User Story 1 的两个 Acceptance Scenario。2.3 Schema History版本化执行的基石T005T005 Add SQLite schema history/version runner 对应 SqliteSchemaVersionRunner.cs。它的职责是记录每个 Manifest 版本是否已被应用从而支撑 spec.md 的 FR-006记录已应用版本与 FR-007幂等启动物化某版本未应用时执行生成的 DDL 并写入版本记录已应用时直接跳过不重复执行任何 Schema 操作。这正是 spec.md 中 User Story 2 的验收场景 1 与 2 的运行时保障。2.4 示例 Manifest 与聚焦测试T006、T007、T009T006 要求提供 Secrets 示例 Manifest作为 S1 的冒烟样例来证明一次声明、两路规划T007 为关系型、文档型与版本运行器行为补充聚焦测试T009 的 S1 自审循环已完成。S1 的验证命令在 roadmap.md 中明确给出dotnet test test/unit/Elsa.Persistence.VNext.UnitTests/Elsa.Persistence.VNext.UnitTests.csproj对应的测试工程位于 test/unit/Elsa.Persistence.VNext.UnitTests。三、S2 — Portable SQLite Document Store MVP可移植文档存储的最小可用版本S2 的目标在 SQLite 上实现一个 Provider 无关的文档存储支持保存、加载、删除、索引维护与按声明索引查询T012–T021。除 T021PR 合并与 issue 关闭外全部完成。3.1 文档包络与存储契约T012T012 定义了StoredDocument文档包络存储的元数据与负载与IDocumentStore契约见 Document/IDocumentStore.cs接口包含五个核心方法MaterializeAsync物化 Schema/索引SaveAsync(SaveDocumentRequest, ...)保存并返回StoredDocumentLoadAsync(storageUnit, id, ...)按存储单元与 ID 加载DeleteAsync(storageUnit, id, expectedVersion, ...)删除支持期望版本参数QueryAsync(DocumentQuery, ...)按声明索引查询。3.2 表物化与索引维护T013–T016T013 在 SQLite 侧实现文档表物化SqliteDocumentStore.csT014 实现 save/load/delete 三件套T015 实现通用字段索引存储Generic field index tableT016 关键要求是索引维护与文档写入处于同一事务对应 spec.md Edge Case 中文档保存成功但索引维护失败的场景——同一事务保证了二者要么同时成功、要么同时回滚。3.3 索引查询、并发控制与未索引校验T017–T019T017 实现按声明索引查询DocumentQuery只接受StorageUnit 过滤器字典见 Document/DocumentQuery.cs这从类型层面就限制了查询只能走声明过的索引字段T018 增加乐观并发Optimistic Concurrency配合DeleteAsync的expectedVersion参数冲突时抛出 DocumentStoreConcurrencyException.csT019 增加未索引查询校验查询引用未声明索引的字段时抛出 DocumentQueryNotIndexedException.cs对应 spec.md 的 FR-009/FR-010可移植查询只能走声明索引未支持/未索引查询返回清晰错误与 User Story 3 的验收场景 3。3.4 测试T020T020 为 SQLite 文档存储补充了单元/集成测试覆盖 save/load/delete、事务性索引维护、索引查询与乐观并发。四、S3 — SQL Server And PostgreSQL Relational Document Providers关系型文档 Provider 家族S3 的目标让同一套文档/索引契约在 SQL Server 与 PostgreSQL 上通过T022–T026。T022SQL Server Provider、T023PostgreSQL Provider、T024启动锁定/物化策略已完成T025关系型 Provider 契约测试与 T026PR 合并仍待办。4.1 两个 Provider 的实现SQL Server 侧SqlServerDocumentStore、SqlServerDocumentStoreDialect、SqlServerSchemaSqlRenderer、SqlServerTypeMapper见 src/modules/Elsa.Persistence.VNext.SqlServerPostgreSQL 侧PostgreSqlDocumentStore、PostgreSqlDocumentStoreDialect见 src/modules/Elsa.Persistence.VNext.PostgreSql两者共享关系型文档存储基座 src/modules/Elsa.Persistence.VNext.RelationalRelationalDocumentStore与RelationalDocumentStoreDialect实现Provider 差异隔离在各自包内的验收要求。4.2 启动锁定与物化策略T024T024 要求启动物化具备并发安全策略。spec.md 的 Edge Case 第一条就是多个应用实例并发启动并尝试物化因此 S3 需要在多实例场景下通过启动锁定保证只有一台实例执行 Schema 物化其余实例等待完成后继续避免 DDL 竞争。4.3 验证前提roadmap.md 的本地进度注明Provider 包与 SQL 方言测试已在本地实现但真实的 SQL Server/PostgreSQL 契约测试需要运行中的 Docker/Testcontainers 环境或 CI worker。即 T025 属于代码就绪、环境受限的待办这一点在阅读任务清单时应结合 roadmap 的说明理解。五、S4 — MongoDB Document Provider原生文档数据库支持S4 的目标同一存储/索引模型在 MongoDB 上以原生集合与原生索引运行T027–T032。T027–T030 完成T031契约测试与 T032PR 合并待办。5.1 原生物化与查询翻译T027 实现 MongoDB 文档 ProviderMongoDbDocumentStore.csT028 物化原生集合与索引MongoDbDatabasePlanner把 Manifest 规划为MongoDbDatabasePlan含MongoDbCollectionPlan、MongoDbIndexPlan见 src/modules/Elsa.Persistence.VNext.MongoDbT029 实现声明索引的查询翻译让可移植查询走 MongoDB 原生查询/索引模型对应 spec.md User Story 4 的验收场景 2T030 增加乐观并发——roadmap.md 特别指出 MongoDB 侧通过期望版本写入/删除过滤器expected-version write/delete filters实现即保存/删除时携带期望版本号由 MongoDB 端原子地校验。5.2 事务与拓扑的边界spec.md 的 Edge Case 提醒MongoDB 事务支持在部分部署拓扑中不可用。因此乐观并发的实现不应依赖多文档事务而是依赖单文档原子操作与版本字段——这也是 T030 采用 expected-version 过滤器的原因。T031 的本地实现同样已完成但真实契约测试需要运行中的 MongoDB 服务或 CI workerroadmap.md 本地进度注明。六、S5 — Elsa Integration And First Module Migration接入 Elsa 并迁移第一个模块S5 的目标Elsa 消费 vNext 持久化至少一个真实模块不再需要 EF Core 迁移T033–T038。T033–T036 完成T037如需则提供 EF Core 存量导入/迁移路径与 T038PR 合并待办。6.1 集成包与特性注册T033–T034T033 增加 Elsa vNext 持久化集成包即 src/modules/Elsa.Persistence.VNext.ExtensionsT034 增加 Shell 特性/选项/启动物化PersistenceVNextFeature.cs 以 Elsa 特性系统FeatureBase注册 vNextConfigureOptions回调可配置PersistenceVNextOptionsPersistenceVNextStartupTask.cs 在应用启动时执行物化DefaultPersistenceSchemaCatalog.cs 实现IPersistenceSchemaCatalog聚合各模块贡献的 Manifest。6.2 诊断输出T035T035 增加已应用 Manifest 与 Provider 状态诊断对应 FR-017暴露 Manifest 版本、Provider 状态与物化失败诊断。实现载体为 DefaultPersistenceVNextStatus.cs 与 PersistenceVNextStatusSnapshot.cs通过IPersistenceVNextStatus契约对外暴露状态快照。6.3 Secrets 模块迁移T036T036 实现 Secrets vNext 存储是 spec.md 中Secrets 是首选迁移的真实模块这一假设的直接落地。roadmap.md 本地进度注明Secrets 现有 EF Core 持久化保持不变存量数据导入/迁移路径T037刻意留待存储模型进一步验证后再决定——对应 spec.md 的 FR-015现有模块逐步迁移与 Edge Case存量 EF Core 数据必须导入 vNext 存储。6.4 迁移的验收标准S5 的验收标准roadmap.mdSecrets 可在 vNext 持久化上运行Secrets vNext不再需要 Provider 专属的 EF Core 迁移包对应 FR-016EF Core 迁移退出 vNext 的 Schema 权威路径现有行为保持不变。七、S6 — Runtime-Defined Entities管理员运行时定义实体S6 的目标管理员可在运行时定义实体发布后持久化并按声明索引查询默认不按实体建物理表T039–T044。T039–T043 完成T044PR 合并待办。7.1 运行时实体模型与生命周期T039–T040T039 定义运行时实体定义模型集中在 src/modules/Elsa.Persistence.VNext.Runtime/ModelsRuntimeEntityDefinition包含Id、Name、Version、Status、Fields、Indexes与审计时间戳见 RuntimeEntityDefinition.csRuntimeEntityFieldDefinition/RuntimeEntityFieldType/RuntimeEntityIndexDefinition字段与索引声明RuntimeEntityInstance运行时实体的实例以文档形式存储。T040 实现 draft/published/retired 生命周期状态枚举见 RuntimeEntityDefinitionStatus.cs对应 FR-013。7.2 校验与能力检查T041T041 由 RuntimeEntityDefinitionValidator.cs 承担草稿实体发布前必须通过校验字段类型、索引声明、Provider 能力等对应 spec.md 的 FR-004物化前 Provider 能力校验。7.3 CRUD/API 与审计T042–T043T042 由 IRuntimeEntityManager.cs 与 RuntimeEntityManager.cs 提供服务级 CRUD/查询 API。roadmap.md 本地进度明确POC 刻意不添加 Studio UI 与 HTTP 端点只提供服务层 APIT043 增加审计轨迹载体为 RuntimeEntityAuditRecord.cs。7.4 不按实体建表的设计要点S6 的验收标准强调默认不要求为每个运行时实体创建物理表。这正是文档存储模型的价值所在实体实例以文档 声明索引的方式落在通用存储中避免每实体一表的爆炸式物理结构而按需的物理化优化留到 S7 的策略机制处理。八、S7 — Physicalization And Performance按策略的物理化与性能优化S7 的目标热点实体与索引可选入 Provider 优化的物理存储形态且不修改模块 Manifest 代码T045–T049。T045–T047 完成T048基准测试与 T049PR 合并待办。8.1 存储策略模型T045T045 在 src/modules/Elsa.Persistence.VNext/Physicalization 目录落地StoragePhysicalizationPolicy每个存储单元/索引选择的优化模式PhysicalizedIndexPolicy索引级优化策略PhysicalizationTarget/PhysicalizationPlan物理化目标与执行计划IPhysicalizationPlanner物理化规划器契约PhysicalizationPolicyValidator策略校验负责Provider 不支持某物理化形态时在应用前报告spec.md User Story 6 验收场景 2也是 FR-004 的延续。8.2 两个 Provider 的物理化示例T046–T047T046 为关系型 Provider 实现优化的索引SQLite 侧由 SqlitePhysicalizationPlanner.cs 规划专用表/索引 DDLT047 为文档 Provider 实现原生优化MongoDB 侧由 MongoDbPhysicalizationPlanner.cs 规划专用集合/原生索引操作。二者共同遵守 roadmap.md 的验收要求可移植默认保持不变——策略是 opt-in 的逃生舱不是默认行为。T048 的真实工作负载基准测试仍待办这与 S8 的基准门控直接相关。九、S8 — Workflow Runtime Evaluation And Hardening工作流运行时评估与加固S8 的目标对工作流运行时热路径做基准评估、并发/锁定验证与生产化加固输出明确的 go/no-go 决策T050–T054。T052、T053 完成T050、T051、T054 待办。9.1 运行时候选评估T053T053 的产物集中在 src/modules/Elsa.Persistence.VNext.Runtime/EvaluationWorkflowRuntimePersistenceEvaluator运行时评估器WorkflowRuntimePersistenceCandidate候选存储的刻画名称、负载特征WorkflowRuntimePersistenceDecision决策记录包含DecisionKind、Reasons与RequiredEvidence见 WorkflowRuntimePersistenceDecision.cs。决策类型WorkflowRuntimePersistenceDecisionKind定义了四种出路AdoptVNext直接采用 vNextAdoptWithPhysicalization采用 vNext 但需配合物理化策略DeferUntilBenchmarked推迟到基准测试后决定KeepSpecializedProvider保留专用 Provider。9.2 当前的评估结论roadmap.md 本地进度roadmap.md 明确记录了当前分类元数据/模块类存储Metadata/Module stores被分类为 vNext 的优质候选good vNext candidates热点查找类存储Hot lookup stores基准测试门控benchmark-gated即必须等 T050 基准数据才能进入 go 状态队列/日志类工作负载Queue/log workloads保持专用 Provider 候选specialized-provider candidates。这正好印证了 spec.md 假设中的工作流运行时热路径后续评估不是首个迁移目标。真实 Provider 基准测试T050与并发/锁定契约测试T051仍然开放。9.3 诊断与恢复指导T052T052 增加 Provider 诊断与恢复指导与 S5 的诊断输出T035一脉相承共同服务于Provider 状态报告与物化失败诊断这一运维闭环。十、任务状态总览与剩余工作下表汇总 8 个阶段的任务完成度依据 tasks.md 原始勾选状态阶段主题已完成待办未合并/未完成S1核心 Manifest 与规划器基础T001–T007, T009T008开/更新 PR、T010合并、T011关闭 issueS2SQLite 可移植文档存储 MVPT012–T020T021PR 合并与 issue 关闭S3SQL Server / PostgreSQL 关系型 ProviderT022–T024T025契约测试依赖 Docker/Testcontainers 或 CI、T026S4MongoDB 文档 ProviderT027–T030T031契约测试依赖 MongoDB 服务或 CI、T032S5Elsa 集成与首个模块迁移T033–T036T037存量 EF Core 导入路径视需要、T038S6运行时定义实体T039–T043T044S7物理化与性能T045–T047T048基准测试、T049S8运行时评估与加固T052, T053T050运行时基准、T051并发/锁定验证、T054整体来看架构主体S1–S7 的编码部分均已实现剩余工作集中在三类PR 合并与 issue 收尾T008/T010/T011、T021、T026、T032、T038、T044、T049、T054属于流程性待办依赖环境的契约/集成测试T025、T031、T051需要 Docker/Testcontainers、CI worker 或真实数据库服务基准与决策证据T048、T050基准测试开放直接决定运行时热路径的 go/no-go。十一、验证与运行方式任务的本地验证入口来自 roadmap.md为dotnet test test/unit/Elsa.Persistence.VNext.UnitTests/Elsa.Persistence.VNext.UnitTests.csproj该测试工程覆盖 S1 的关系型、文档型与版本运行器行为。其余阶段的验证分布在各 Provider 包的聚焦测试中真实数据库契约测试SQL Server / PostgreSQL / MongoDB需要运行中的数据库服务或 CI worker。若要在应用内启用 vNext可通过 PersistenceVNextFeature 以 Elsa 特性系统方式注册并用ConfigureOptions配置 PersistenceVNextOptions.cs启动时由PersistenceVNextStartupTask完成 Schema/索引物化。十二、相关文档与源码索引继续深入阅读的仓库入口任务清单specs/011-persistence-vnext/tasks.md功能规范用户故事、需求 FR-001–FR-018、成功标准specs/011-persistence-vnext/spec.md可执行路线图范围、验收、issue 映射、本地进度specs/011-persistence-vnext/roadmap.md规范质量检查清单specs/011-persistence-vnext/checklists/requirements.md核心模型与规划器src/modules/Elsa.Persistence.VNextModels、Relational、Document、Contracts、PhysicalizationSQLite 实现src/modules/Elsa.Persistence.VNext.SqliteSQL Server 实现src/modules/Elsa.Persistence.VNext.SqlServerPostgreSQL 实现src/modules/Elsa.Persistence.VNext.PostgreSqlMongoDB 实现src/modules/Elsa.Persistence.VNext.MongoDbElsa 集成包src/modules/Elsa.Persistence.VNext.Extensions运行时实体与运行时评估src/modules/Elsa.Persistence.VNext.Runtime单元测试工程test/unit/Elsa.Persistence.VNext.UnitTests结语specs/011-persistence-vnext/tasks.md 是 Elsa Persistence vNext 从规范走向实现的最直接证据54 个任务把Provider 无关存储清单 规划器/渲染器 可移植文档存储 多 Provider 物化 运行时实体 物理化策略 运行时评估这条完整架构链拆解为可独立验证的增量步骤。结合 spec.md 的需求与 roadmap.md 的进度说明可以确认核心编码已基本完成当前主战场在 PR 收尾、真实数据库契约测试与基准决策。对于希望参与或评估该架构的开发者S1 的同一 Manifest 双路规划、S2 的事务性索引维护 乐观并发、S8 的四类 go/no-go 决策是最值得优先研读的三个切入点。赞分享后端工作流自动化流程编排低代码【免费下载链接】elsa-coreThe Workflow Engine for .NET项目地址https://gitcode.com/gh_mirrors/el/elsa-core点击查看免费下载相关推荐Elsa Persistence vNext 执行路线图解析从模块存储清单到可移植文档存储的八阶段演进Elsa Persistence vNext 执行路线图解析从模块存储清单到可移植文档存储的八阶段演进 本文以 specs/011 persistence v后端工作流自动化流程编排低代码Elsa Persistence vNext 工作流运行时持久化评估哪些存储该迁移哪些必须保留专用 ProviderElsa Persistence vNext 工作流运行时持久化评估哪些存储该迁移哪些必须保留专用 Provider Persistence vNext 是后端工作流自动化流程编排低代码Elsa Persistence vNext 路线图深度解析让模块声明一次存储意图、由数据库提供方物化物理模型Elsa Persistence vNext 路线图深度解析让模块声明一次存储意图、由数据库提供方物化物理模型 导读 本文基于 design/persiste后端工作流自动化流程编排低代码上一篇Algorithms 项目 Fenwick Tree树状数组 / 二叉索引树双形态实战指南区间查询、区间更新与点操作的 O(log n) 实现解析下一篇3个核心技术解密Unity游戏实时翻译引擎的架构演进创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考