@warlock.js/cascade 4.4.0 → 4.5.0

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.
Files changed (2) hide show
  1. package/CHANGELOG.md +3 -3
  2. package/package.json +4 -4
package/CHANGELOG.md CHANGED
@@ -8,7 +8,7 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/).
8
8
 
9
9
  ### Changed
10
10
 
11
- - **Documented `model.uuid`** — clarified that the accessor returns the model's primary id as `string` (where `model.id` is `string | number`); the name is historical and performs no UUID validation or coercion.
11
+ - **Documented `model.uuid`** — the accessor returns the model's primary id as `string` (where `model.id` is `string | number`); the name is historical and performs no UUID validation.
12
12
 
13
13
  ## 4.2.11
14
14
 
@@ -35,11 +35,11 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/).
35
35
 
36
36
  ### Changed
37
37
 
38
- - MongoDB and PostgreSQL drivers now log a failed initial `connect()` at `log.fatal` (was `log.error`). Boot-time database connection failures are unrecoverable in every realistic Warlock use case (app boot, CLI migrations, workers) — `fatal` makes "page on fatal only" alerting clean. Per-query failures, `createDatabase`/`dropDatabase` lifecycle errors, and disconnect failures stay at `error`.
38
+ - MongoDB and PostgreSQL drivers now log a failed initial `connect()` at `log.fatal` (was `log.error`) — a boot-time database connection failure is unrecoverable, so `fatal` keeps "page on fatal only" alerting clean. Per-query and disconnect failures stay at `error`.
39
39
 
40
40
  ### Fixed
41
41
 
42
- - PostgreSQL `increment` / `decrement` (and the `*Many` variants) bound the amount parameter as `$1`, which collided with the first filter placeholder (`SET n = n + $1 WHERE id = $1`) — the filter value bound into the amount slot, so every filtered counter update wrote the wrong number. The amount now binds after the filter params.
42
+ - PostgreSQL `increment` / `decrement` (and the `*Many` variants) bound the amount as `$1`, colliding with the first filter placeholder (`SET n = n + $1 WHERE id = $1`) so every filtered counter update wrote the wrong number; the amount now binds after the filter params.
43
43
 
44
44
  ## 4.1.15
45
45
 
package/package.json CHANGED
@@ -27,9 +27,9 @@
27
27
  "@mongez/events": "^2.2.6",
28
28
  "@mongez/reinforcements": "^3.3.0",
29
29
  "@mongez/supportive-is": "^2.1.3",
30
- "@warlock.js/context": "4.4.0",
31
- "@warlock.js/logger": "4.4.0",
32
- "@warlock.js/seal": "4.4.0",
30
+ "@warlock.js/context": "4.5.0",
31
+ "@warlock.js/logger": "4.5.0",
32
+ "@warlock.js/seal": "4.5.0",
33
33
  "citty": "^0.2.2",
34
34
  "fast-glob": "^3.3.3"
35
35
  },
@@ -40,7 +40,7 @@
40
40
  "bin": {
41
41
  "cascade": "bin/cascade.js"
42
42
  },
43
- "version": "4.4.0",
43
+ "version": "4.5.0",
44
44
  "main": "./cjs/index.cjs",
45
45
  "module": "./esm/index.mjs",
46
46
  "types": "./esm/index.d.mts",