@prisma/orm-sqlite 8.0.0-rc.11-dev.55 → 8.0.0-rc.12-dev.1

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@prisma/orm-sqlite",
3
- "version": "8.0.0-rc.11-dev.55",
3
+ "version": "8.0.0-rc.12-dev.1",
4
4
  "license": "Apache-2.0",
5
5
  "type": "module",
6
6
  "sideEffects": false,
@@ -10,17 +10,17 @@
10
10
  "skills"
11
11
  ],
12
12
  "dependencies": {
13
- "@prisma/orm-family-sql": "8.0.0-rc.11-dev.55",
14
- "@prisma/orm-framework": "8.0.0-rc.11-dev.55",
15
- "@prisma/orm-target-sqlite": "8.0.0-rc.11-dev.55",
16
- "@prisma/orm-toolchain": "8.0.0-rc.11-dev.55",
13
+ "@prisma/orm-family-sql": "8.0.0-rc.12-dev.1",
14
+ "@prisma/orm-framework": "8.0.0-rc.12-dev.1",
15
+ "@prisma/orm-target-sqlite": "8.0.0-rc.12-dev.1",
16
+ "@prisma/orm-toolchain": "8.0.0-rc.12-dev.1",
17
17
  "pathe": "^2.0.3",
18
18
  "tinyglobby": "^0.2.17"
19
19
  },
20
20
  "devDependencies": {
21
- "@internal/sqlite": "8.0.0-rc.11-dev.55",
22
- "@repo/tsconfig": "8.0.0-rc.11-dev.55",
23
- "@repo/tsdown": "8.0.0-rc.11-dev.55",
21
+ "@internal/sqlite": "8.0.0-rc.12-dev.1",
22
+ "@repo/tsconfig": "8.0.0-rc.12-dev.1",
23
+ "@repo/tsdown": "8.0.0-rc.12-dev.1",
24
24
  "tsdown": "0.22.14",
25
25
  "typescript": "5.9.3"
26
26
  },
@@ -15,7 +15,7 @@ description: >-
15
15
  ORM 7 or earlier (schema.prisma + @prisma/client).
16
16
  metadata:
17
17
  library: '@prisma/orm-sqlite'
18
- library_version: '8.0.0-rc.11-dev.55'
18
+ library_version: '8.0.0-rc.12-dev.1'
19
19
  version: '2026-09-12'
20
20
  ---
21
21
 
@@ -73,7 +73,7 @@ It is **offline** — it never consults a database, never reads a marker (which
73
73
 
74
74
  When the origin came from the `db` ref by default and that node **already has an outgoing migration**, the plan still succeeds but warns: planning from there forks the graph. Pass `--from` to name the origin deliberately if that is what you want.
75
75
 
76
- **`migration new` picks its origin the same way.** With `--from <hash-or-prefix>` it uses that migration's `to` hash. Without `--from`: the `db` ref, else greenfield on an empty graph, else `MIGRATION.PLAN_ORIGIN_UNKNOWN`. It never chains from "the newest migration on disk" — there is no such node.
76
+ **`migration new` picks its origin the same way, with one difference.** With `--from <hash-or-prefix>` it uses that migration's `to` hash. Without `--from`: the `db` ref (which must be a graph node), else greenfield on an empty graph, else `MIGRATION.PLAN_ORIGIN_UNKNOWN`. The difference: on an empty graph that has a `db` ref, `migration plan` writes the baseline (auto-baseline above) while `migration new` refuses with `MIGRATION.HASH_NOT_IN_GRAPH` and tells you to run `migration plan` first. Neither command ever chains from "the newest migration on disk" — there is no such node.
77
77
 
78
78
  The human output names the resolved origin on its `from:` line. **`from: (baseline)` means the origin resolved to nothing — the plan starts from an empty database** and will contain a create for every object in the contract.
79
79