mirror of
https://github.com/jxxghp/MoviePilot.git
synced 2026-10-30 03:48:03 +08:00
3d594ecee3
插件配置此前借用 systemconfig 的 plugin.<实例ID> 单键，为了换表又在
SystemConfigOper 的 set/delete/load_snapshot 里按该前缀开分支。这是反向依赖：
一个对所有键一视同仁的通用键值存储被迫知道「插件」这个概念，读写路径依键值而
异，「这个键落在哪张表」只有读代码才说得清；规范方法按值加特例，也让此后任何新
键都要先确认自己会不会被拦截。
本次把插件配置整条链拆出，形状与本分支日志等级那条链一致：
- SystemConfigOper 整体回退到官方实现，与 f70d7c141 逐字节相同，对所有键一视同仁。
- 配置端口改按实例 ID 寻址：PluginStorage 新增 read_config / write_config /
async_write_config / delete_config，PluginConfigStore 去掉 key_prefix 与 _key，
不再有任何字符串键经过；plugin_exists 存在性规则、空键过滤与 force 语义不变。
- PluginInstanceOper 补齐读取与异步写入原语 get_config_data /
async_save_config_data，同步与异步共用同一份落库决策，避免两条路径对「值未变化
不写」和「建行用哪个源插件」各自分叉。
- _PluginBase 的 get_config / update_config 直连 PluginInstanceOper，方法名、签名、
返回与 docstring 不变；self.systemconfig 保留，插件读 SystemConfigKey 枚举值仍
然合法，插件公开面没有扩大。
插件直接用 SystemConfig 存取自身配置不予支持。它本就不是封装过的插件配置通道，
为它设计兼容或加守卫拦截，等于再把「插件」塞回通用存储里——那正是本次要拆掉的东
西。拆开后 plugin.<ID> 只是一个与插件无关的普通 systemconfig 键：迁移已经把旧的
plugin.* 行搬进插件实例表，读它拿到 None，写它会新增一条谁也不读的 systemconfig
记录，插件配置通道既不读也不写它，两边不会再有任何交叉。
代价是读取从内存快照变成一次按实例 ID 的主键查询。调用点都不在热路径上：宿主侧
只有插件启动/重载、配置表单接口与分身创建三处，插件侧 get_config() 惯例在
init_plugin 里取一次。写入侧没有变化，本来就是一次事务。
回归防线：新增用例断言 SystemConfigOper 对 plugin. 前缀没有任何特殊行为——写进去
就是一行普通 systemconfig 记录，读出来就是刚写的值，不会被路由到插件实例表。
兼容层零改动，三个 alembic 迁移一行未改。
Documentation Hub
This repository maintains a structured documentation library covering the full development lifecycle. All rule documents live in the docs/rules/ directory. This index maps each file to its technical domain and intended reader.
Technical Document Index
Section I: Foundation and Environment
-
01 Project Overview
- File:
01-project-overview.md - Scope: System goals, business domain, deployment models, and what is and is not in this repository.
- File:
-
02 Tech Stack
- File:
02-tech-stack.md - Scope: Frameworks, languages, libraries, runtime environments, and third-party integrations.
- File:
-
03 Commands
- File:
03-commands.md - Scope: CLI reference, development triggers, testing commands, linting, and dependency management.
- File:
Section II: Architecture and Logic
-
04 Design Patterns
- File:
04-design-patterns.md - Scope: Project-specific structural, creational, and behavioral patterns: Module, Chain, Event, Oper, Config Reload, Singleton.
- File:
-
05 Architecture and Modules
- File:
05-architecture.md - Scope: Layer boundaries, dependency directions, module categories, and the canonical call graph.
- File:
-
09 External APIs, Protocols, and Responses
- File:
09-external-response.md - Scope: HTTP client conventions, MCP protocol, standardized response formats, and error handling by layer.
- File:
-
10 Data and Persistent Management
- File:
10-data-and-persistent.md - Scope: SQLAlchemy models, Alembic migrations, Oper access layer, SystemConfig, caching patterns.
- File:
Section III: Implementation Standards
-
06 Code Standards and Style
- File:
06-code-styles.md - Scope: Type annotations, Pydantic usage, async patterns, imports, formatting, and error handling rules.
- File:
-
07 Naming Conventions
- File:
07-naming-conventions.md - Scope: Strict taxonomy for files, classes, functions, constants, and schema models.
- File:
-
08 Comments and Documentation Style
- File:
08-comment-styles.md - Scope: Chinese docstring requirements, inline comment rules, and prohibited comment anti-patterns.
- File:
Section IV: Quality and Governance
-
11 Code Quality and Security
- File:
11-quality-and-security.md - Scope: Testing requirements, pylint gates, dependency vulnerability scans, authentication patterns, and input validation rules.
- File:
-
12 Collaboration, Versioning, Build, and Release
- File:
12-collaboration-and-distribution.md - Scope: Conventional Commits, branch policy, release workflow, Docker build, and version management.
- File:
Reader Persona Guidance
Core Developers and Implementers
Developers actively writing or modifying features should follow this reading path:
- 07 Naming Conventions — establishes the lexicon for the feature.
- 06 Code Standards — ensures linting and logic compliance.
- 04 Design Patterns — identifies the correct structural approach.
- 03 Commands — required for local execution and validation.
System Architects and Reviewers
Personnel focused on system integrity and long-term maintenance:
- 05 Architecture and Modules — for verifying structural boundaries.
- 10 Data and Persistent Management — for auditing data integrity and storage efficiency.
- 09 External APIs — for reviewing integration security and protocol compliance.
- 11 Code Quality and Security — for establishing the PR approval baseline.
Operations and Release Engineers
Those managing the application lifecycle post-development:
- 12 Collaboration and Versioning — for release tags and branch management.
- 02 Tech Stack — for environment provisioning and dependency management.
- 11 Code Quality and Security — for verifying deployment-ready security posture.
Document Interconnectivity
- Architecture (05) references Code Standards (06) for layer isolation and module boundary rules.
- Naming Conventions (07) works in tandem with Comment Styles (08) to define overall code readability.
- External APIs (09) relies on Tech Stack (02) for transport layer specifications and HTTP client selection.
- Data Management (10) is governed by Quality and Security (11) for sensitive data handling requirements.
- Design Patterns (04) is the implementation reference for decisions documented in Architecture (05).
Last Updated: 2026-08-24