Add net-new self-referencing hierarchy support to book
Table of Contents
This page is a capture in the discarded bucket of the product backlog.
Superseded by a later, more considered decision: Task: Document that
book-to-book hierarchy is not supported; hierarchy is via
portfolios (2026-07-08, in Book data model cleanup) established that
book-to-book hierarchy is a deliberate non-feature — hierarchy is
expressed entirely via the portfolio tree (Portfolio has
self-referencing parent_portfolio_id; Book links to exactly one
portfolio). Adding parent_book_id as this capture proposed would
contradict that decision. Discarded rather than promoted.
What
book currently has no self-referencing hierarchy at all (no
parent_book_id). Add one, using the has_parent_id SQL Flag pattern
already built and proven for party=/=counterparty
(parent_id_column, hierarchy_name_field, generated
ores_refdata_books_hierarchy_fn), plus a hand-written or (by then,
possibly generated) get_book_hierarchy NATS message.
Why
Book trees (desk/book org structure) are a real product need, and
this is now a proven, cheap-to-apply pattern rather than net-new
design work. Deliberately scoped out of the Generalize
self-referential hierarchy task because adding a hierarchy to an
entity that never had one is a bigger, separate product-scoping
question (does book have a "root per tenant" concept the way party's
system party does? does every book need a parent, or is it optional
for top-level books?) than migrating an existing hand-written pattern.
References
projects/ores.sql/create/refdata/refdata_parties_create.sql/refdata_counterparties_create.sql— reference_hierarchy_fnimplementations.projects/ores.codegen/modeling/org_entity_meta_model.org—has_parent_idFlag documentation.