@stonyx/orm 0.3.2-alpha.52 → 0.3.2-alpha.53

package/README.md

@@ -568,6 +568,13 @@ sub-paths beneath the mount, as the `/archived` deny above does.
   [#205](https://github.com/abofs/stonyx-orm/issues/205), alongside
   [#203](https://github.com/abofs/stonyx-orm/issues/203), which is the other way
   a create can land on an id nobody named.
+- **`context.record` is `undefined` for an after-`create` hook when a string-id
+  model is given a numeric-looking id.** The post-create lookup uses the same id
+  coercion as every other surface, which resolves `'9107'` to the number `9107`,
+  while a model declaring `id = attr('string')` files the record under the string
+  key. The create itself succeeds and `context.response.data` is correct; only
+  the hook's view of the record is wrong, and it is wrong *silently*. Tracked as
+  [#209](https://github.com/abofs/stonyx-orm/issues/209).
 - **A denied `POST` rolls back only a record it *inserted*.** The rollback
   requires the store to have grown, because removing by id alone is a write
   primitive keyed by a caller-supplied value. When `assignRecordId` lands a

package/dist/orm-request.js

@@ -135,6 +135,16 @@ function getBaseUrl(request) {
  * every input reachable there, which is exactly what the two that DID diverge
  * looked like until someone tried a hex id.
  *
+ * SHARING IT IS NOT THE SAME AS IT BEING RIGHT EVERYWHERE. On a model declaring
+ * `id = attr('string')` a numeric-looking id is filed under the STRING key, so
+ * this coercion resolves `'9107'` to `9107` and the post-create lookup misses:
+ * `context.record` is `undefined` for an after-`create` hook. Inherited -- the
+ * inlined copy computed the same thing -- and NOT fixed here, because picking
+ * the right coercion needs the model's declared id type, which is the same
+ * structural information abofs/stonyx-orm#202 is about. Filed as
+ * abofs/stonyx-orm#209 and pinned by assertion 50, so closing it turns a test
+ * red rather than passing silently.
+ *
  * `parseInt` and not `Number`, deliberately, and the anchor is NOT `getId`.
  * It is `src/transforms.ts:7` -- `number: (value) => parseInt(value as string)`,
  * also radix-less -- because that transform is what actually produces the store

package/package.json

@@ -4,7 +4,7 @@
     "stonyx-async",
     "stonyx-module"
   ],
-  "version": "0.3.2-alpha.52",
+  "version": "0.3.2-alpha.53",
   "description": "",
   "main": "dist/index.js",
   "type": "module",

package/src/orm-request.ts

@@ -171,6 +171,16 @@ function getBaseUrl(request: OrmRequest$): string {
  * every input reachable there, which is exactly what the two that DID diverge
  * looked like until someone tried a hex id.
  *
+ * SHARING IT IS NOT THE SAME AS IT BEING RIGHT EVERYWHERE. On a model declaring
+ * `id = attr('string')` a numeric-looking id is filed under the STRING key, so
+ * this coercion resolves `'9107'` to `9107` and the post-create lookup misses:
+ * `context.record` is `undefined` for an after-`create` hook. Inherited -- the
+ * inlined copy computed the same thing -- and NOT fixed here, because picking
+ * the right coercion needs the model's declared id type, which is the same
+ * structural information abofs/stonyx-orm#202 is about. Filed as
+ * abofs/stonyx-orm#209 and pinned by assertion 50, so closing it turns a test
+ * red rather than passing silently.
+ *
  * `parseInt` and not `Number`, deliberately, and the anchor is NOT `getId`.
  * It is `src/transforms.ts:7` -- `number: (value) => parseInt(value as string)`,
  * also radix-less -- because that transform is what actually produces the store