Skip to content

os start / os dev--database 描述手写了一份 URL scheme 举例,相对 inferDriverTypeFromUrl 实际识别的 scheme 不完整 #7028

Description

@os-project-manager

observation 级(今天没有用户会撞到)——由 #6969 顺手发现,按 Prime Directive #10 不在那个 PR 里修。

现状

packages/cli/src/commands/start.tsdev.ts--database flag 描述里手写了一串 URL scheme 举例:

Database URL: file:./db.sqlite | libsql://... | postgres://... | mongodb://... | memory://

而真正决定「哪些 scheme 会被识别成驱动」的是 packages/cli/src/utils/storage-driver.tsinferDriverTypeFromUrl()。两边对照,散文里没提到的还有:mysql:// / mysql2://sqlite:wasm-sqlite://mongodb+srv://:memory:.db / .sqlite / .sqlite3 后缀、以及 https://*.turso.*

为什么归为 observation 而不是缺陷

可选的收口方向(留给 triage 定夺,不预设)

  1. 什么都不做——举例就是举例。
  2. 把散文补齐到与 inferDriverTypeFromUrl 一致(治标:仍是手写副本,仍会漂移)。
  3. 先让 scheme 词表有一处定义(例如把 inferDriverTypeFromUrl 的匹配改成表驱动),再让描述从它派生——与 cli/runtime: explicit driver(--database-driver / OS_DATABASE_DRIVER)在 CLI 与 standalone stack 之间仍有三处分叉(#6265 后续) #6345 / --database-driver 的 oclif 白名单改为从共享驱动表推导 —— 裁定第 3 项「一个词表、一处推导」的后半(阻塞于 PR #6910) #6969 对驱动 id 走的是同一条路。方向 3 才是结构性的,但它要的是一次真正的重构,不是文案修补。

关联

#6969(驱动 id 词表的同类收口,本 finding 的来源)· #6345(一个词表、一处推导)· packages/cli/src/utils/storage-driver.tsinferDriverTypeFromUrl()

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions