lhumina_code/hero_blueprint
1
0
Fork 0
Code Issues 22 Pull requests Projects Releases 4 Packages Wiki Activity Actions

Align OSIS CRUD codegen to hero_lib 979c1781: drop _new, _set upsert with full object, no <Type>Input #155

New issue
Open
opened 2026-06-02 08:55:59 +00:00 by timur · 2 comments
timur commented 2026-06-02 08:55:59 +00:00
Owner
Copy link

Summary

Kristof simplified OSIS CRUD/OpenRPC generation in hero_lib commit 979c1781 (crates/oschema/src/oschema/openrpc.rs). hero_blueprint's OSIS generator still emits the old shape and must be aligned. Confirmed against origin/development.

The new shape (hero_lib oschema/openrpc.rs, post-979c1781)

Per [rootobject], CRUD methods are now: _get, _set, _delete, _list, _list_full, _exists, _find — _new is GONE.

  • _set is the single write entry point (upsert) — openrpc.rs:543. Its data param is "A full {ty} object — the same schema {wire}_get returns. Leave sid empty/absent to create (server mints it); set it to a server-issued sid to update." Returns the SmartID. (Quote: "there is no separate new".)
  • One schema per object — the data param and the _get result both reference the full object schema (ref_full). There is no separate <Type>Input / ObjectInput schema anymore (the old "Input shape … without server-managed base fields sid/created_at/updated_at" component is removed).
  • Flat wire names with _ (e.g. user_set, user_get) — not user.set.

What hero_blueprint still does (old shape — to change)

crates/generator/src/:

  • rust/rust_osis.rs — emits _new(data: <Type>Input) and _set(sid, data: <Type>Input) -> bool; RPC handlers _rpc_new / _rpc_set(sid,data).
  • rust/rust_struct.rs — emits the separate <Type>Input struct (~943) + From<&Type> for <Type>Input.
  • schemas/openrpc.rs — emits the _new method spec + separate input schema.
  • derive/openrpc_client.rs — SDK has new + <Type>NewInput flattening.

Change list

  1. Drop _new everywhere (generator methods, RPC handlers, OpenRPC spec, SDK).
  2. _set → upsert taking the full object (<Type>, with sid): empty/absent sid ⇒ create (mint sid), present sid ⇒ update. Returns SmartID (string). Remove the (sid, Input) two-param form.
  3. Remove the <Type>Input struct + its schema; _set/_get use the full object schema. Storage layer already strips/stamps sid/created_at/updated_at on create.
  4. SDK (openrpc_client!): drop new; set(obj: <Type>).
  5. Regenerate hero_osis (15 domains) + CRM example; fix any preserved server/rpc.rs stubs, admin create-forms (call _set with empty sid, not _new), and tests asserting the old surface.

Intersection with recent OSIS work (mostly orthogonal)

The async .await on DBTyped call sites, the hero_db storage migration, the [index]→@index schema migration, and per-domain serving are unaffected by the method/struct-shape change — except the _new handler is removed and the _set handler now takes the full object (sid-aware create-or-update), so the create path in rust_osis.rs's emitted handlers + the From<&Type> for Input conversion go away.

Bigger picture

This is the codegen-shape half of converging OSIS onto hero_lib's model; the serving half is #154. Ideally hero_blueprint's OSIS CRUD generation reuses hero_lib's oschema/openrpc.rs shape rather than maintaining a parallel emitter.

References

  • hero_lib commit 979c1781; crates/oschema/src/oschema/openrpc.rs:520-640 (CRUD emit), :164 (set input check).
  • hero_blueprint: crates/generator/src/rust/rust_osis.rs, rust/rust_struct.rs, schemas/openrpc.rs, derive/openrpc_client.rs.
  • Our branches: hero_osis feature/osis-hero-db-storage; hero_blueprint feature/osis-hero-db-storage + feature/osis-multidomain-serve.

Filed with context from the hero_osis re-architecture (Claude).

## Summary Kristof simplified OSIS CRUD/OpenRPC generation in hero_lib commit **`979c1781`** (`crates/oschema/src/oschema/openrpc.rs`). hero_blueprint's OSIS generator still emits the **old** shape and must be aligned. Confirmed against `origin/development`. ## The new shape (hero_lib `oschema/openrpc.rs`, post-979c1781) Per `[rootobject]`, CRUD methods are now: **`_get`, `_set`, `_delete`, `_list`, `_list_full`, `_exists`, `_find`** — **`_new` is GONE.** - **`_set` is the single write entry point (upsert)** — `openrpc.rs:543`. Its `data` param is *"A full `{ty}` object — the same schema `{wire}_get` returns. Leave `sid` empty/absent to **create** (server mints it); set it to a server-issued `sid` to **update**."* Returns the SmartID. (Quote: "there is no separate `new`".) - **One schema per object** — the `data` param and the `_get` result both reference the **full object schema** (`ref_full`). There is **no separate `<Type>Input` / `ObjectInput`** schema anymore (the old "Input shape … without server-managed base fields sid/created_at/updated_at" component is removed). - **Flat wire names** with `_` (e.g. `user_set`, `user_get`) — not `user.set`. ## What hero_blueprint still does (old shape — to change) `crates/generator/src/`: - `rust/rust_osis.rs` — emits `_new(data: <Type>Input)` **and** `_set(sid, data: <Type>Input) -> bool`; RPC handlers `_rpc_new` / `_rpc_set(sid,data)`. - `rust/rust_struct.rs` — emits the separate `<Type>Input` struct (`~943`) + `From<&Type> for <Type>Input`. - `schemas/openrpc.rs` — emits the `_new` method spec + separate input schema. - `derive/openrpc_client.rs` — SDK has `new` + `<Type>NewInput` flattening. ## Change list 1. **Drop `_new`** everywhere (generator methods, RPC handlers, OpenRPC spec, SDK). 2. **`_set` → upsert taking the full object** (`<Type>`, with `sid`): empty/absent `sid` ⇒ create (mint sid), present `sid` ⇒ update. Returns SmartID (string). Remove the `(sid, Input)` two-param form. 3. **Remove the `<Type>Input` struct + its schema**; `_set`/`_get` use the full object schema. Storage layer already strips/stamps `sid`/`created_at`/`updated_at` on create. 4. **SDK (`openrpc_client!`)**: drop `new`; `set(obj: <Type>)`. 5. Regenerate **hero_osis** (15 domains) + **CRM example**; fix any preserved `server/rpc.rs` stubs, admin create-forms (call `_set` with empty sid, not `_new`), and tests asserting the old surface. ## Intersection with recent OSIS work (mostly orthogonal) The async `.await` on `DBTyped` call sites, the hero_db storage migration, the `[index]`→`@index` schema migration, and per-domain serving are unaffected by the method/struct-shape change — except the **`_new` handler is removed** and the **`_set` handler now takes the full object** (sid-aware create-or-update), so the create path in `rust_osis.rs`'s emitted handlers + the `From<&Type> for Input` conversion go away. ## Bigger picture This is the codegen-shape half of converging OSIS onto hero_lib's model; the serving half is #154. Ideally hero_blueprint's OSIS CRUD generation reuses hero_lib's `oschema/openrpc.rs` shape rather than maintaining a parallel emitter. ## References - hero_lib commit `979c1781`; `crates/oschema/src/oschema/openrpc.rs:520-640` (CRUD emit), `:164` (set input check). - hero_blueprint: `crates/generator/src/rust/rust_osis.rs`, `rust/rust_struct.rs`, `schemas/openrpc.rs`, `derive/openrpc_client.rs`. - Our branches: hero_osis `feature/osis-hero-db-storage`; hero_blueprint `feature/osis-hero-db-storage` + `feature/osis-multidomain-serve`. _Filed with context from the hero_osis re-architecture (Claude)._
timur changed title from Align (and confirm) OSIS CRUD / OpenRPC input-struct codegen with Kristof's simplified shape to Align OSIS CRUD codegen to hero_lib 979c1781: drop _new, _set upsert with full object, no <Type>Input 2026-06-02 09:08:34 +00:00
timur commented 2026-06-02 09:12:24 +00:00
Author
Owner
Copy link

Picking this up (together with the paired issue — same OSIS handler regeneration). Working branches: hero_blueprint feature/osis-multidomain-serve (rebased target) + hero_osis feature/osis-hero-db-storage.

Exploring the exact target first: how a storage-backed OSIS handler plugs into hero_lib openrpc_server! (<Domain>Api trait + per-domain router) and serve_rpc_domains. Will post the concrete execution plan here next, then implement in chunks with a comment per chunk so this issue stays a complete record.

**Picking this up** (together with the paired issue — same OSIS handler regeneration). Working branches: hero_blueprint `feature/osis-multidomain-serve` (rebased target) + hero_osis `feature/osis-hero-db-storage`. Exploring the exact target first: how a storage-backed OSIS handler plugs into hero_lib `openrpc_server!` (`<Domain>Api` trait + per-domain router) and `serve_rpc_domains`. Will post the concrete execution plan here next, then implement in chunks with a comment per chunk so this issue stays a complete record.
timur commented 2026-06-02 09:17:02 +00:00
Author
Owner
Copy link

Execution plan + the gating type-ownership decision are journaled on #154 — same regeneration pass covers this issue's _set-upsert/no-_new/single-schema change (it falls out of adopting hero_lib openrpc_server!). Will journal CRUD-shape specifics here as that chunk lands.

Execution plan + the gating **type-ownership decision** are journaled on #154 — same regeneration pass covers this issue's `_set`-upsert/no-`_new`/single-schema change (it falls out of adopting hero_lib `openrpc_server!`). Will journal CRUD-shape specifics here as that chunk lands.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
development
main
main_mik
main_fix_rpc2_casing_and_derive_dep
integration
development_new
development_jan
v0.1.2
v0.6.1
backup/osis-multidomain-serve-approachA
backup/osis-hero-db-storage
latest
v0.1.0
Labels
Clear labels   
prio_critical

   
prio_low

   
type_bug

   
type_contact

   
type_issue

   
type_lead

   
type_question

   
type_story

   
type_task
No labels
prio_critical
prio_low
type_bug
type_contact
type_issue
type_lead
type_question
type_story
type_task
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
lhumina_code/hero_blueprint#155
No description provided.