createWorkingTreeCaptureRuntime()

function createWorkingTreeCaptureRuntime(
   adapter, 
   entityManager, 
   entities, 
   databaseSync
): WorkingTreeCaptureRuntime;

Defined in: packages/rxdb-plugin-working-tree/src/working-tree/capture-hook.ts:653

按一个库的实体登记造出捕获运行时

Parameters

Parameter	Type	Description
`adapter`	`PhysicalTableNameSource`	-
`entityManager`	`EntityManager`	捕获时用来实例化工作树单元
`entities`	readonly `EntityType`[]	这个库注册的全部业务实体（`rxdb.config.entities`）
`databaseSync`	\| `SyncOptions` \| `EntitySyncResolver`	实例解析器 `rxdb.entitySync`（含实例覆盖）；传库级 `rxdb.config.sync` 时只按「实体优先、否则继承库级」解析

Returns

WorkingTreeCaptureRuntime

可直接交给 adapter.setWorkingTreeCaptureHook() 的运行时

Throws

RxDBError 某个实体解析不出生效的同步配置时

Remarks

同步策略走 getEntitySync 而不是直接读 metadata.sync：「实体优先、否则继承库级」这条规则已经有一份实现，在这里重写一遍就等于给 QueryCache 的判定开了第二个入口—— 而版本化域里唯一按 syncType 分叉的判断正是「是不是 QueryCache」。两处一旦分叉，症状是某张缓存表的行开始被捕获成用户编辑，追起来要穿过整条捕获链。

解析不出同步配置时抛而不是当作 Full：RxDBConfig.sync 是必填的，所以这个分支在正常构造下走不到；真走到了说明配置形状已经不是这里以为的样子，此时按「不是 QueryCache」继续，只会把一张缓存表静默地纳入版本化。

系统表先摘出去再建域。 传进来的 rxdb.config.entities 已经被 SchemaManager.init() 补过系统表，照单全收会让 rxdb_branch / rxdb_change 这些表落进 versionedTables，于是 raw 写四步门禁的判定域整个错位——库自己的簿记 SQL 会被当成绕过捕获的业务写而拦下。摘干净之后还多一层作用：域认得的名字必定是业务实体，WorkingTreeCaptureRuntime.targetClassOf 正是靠这一点先问域再问系统表清单。

Parameters​

Returns​

Throws​

Remarks​

Parameters

Returns

Throws

Remarks