kindred/silo
1
1
Fork 0
Code Issues 30 Pull Requests Actions Packages Projects Releases Wiki Activity

feat(db): .kc metadata database migration #140

New Issue
Closed
opened 2026-02-18 20:57:54 +00:00 by forbes · 0 comments
forbes commented 2026-02-18 20:57:54 +00:00
Owner
Copy Link

Add database migration for all .kc server-side metadata tables as specified in KC_SERVER.md Section 3.

Tables to create:

item_metadata (Section 3.1)

Indexes silo/manifest.json and silo/metadata.json from .kc files. Primary key on item_id. Stores schema_name, tags (TEXT[]), lifecycle_state, fields (JSONB), kc_version, manifest_uuid, silo_instance, revision_hash.

Indexes: GIN on tags, B-tree on lifecycle_state, GIN on fields.

item_dependencies (Section 3.2)

Indexes silo/dependencies.json -- CAD-extracted assembly relationships. Columns: parent_item_id, child_uuid, child_part_number, child_revision, quantity, label, relationship, revision_number.

Complements (does not replace) the existing relationships table. This is the CAD-authoritative record; relationships is the server-authoritative BOM.

item_approvals + approval_signatures (Section 3.3)

ECO workflow tables. item_approvals: item_id, eco_number, state, updated_at, updated_by. approval_signatures: approval_id FK, username, role, status, signed_at, comment.

item_macros (Section 3.4)

Registers macros from silo/macros/. Columns: item_id, filename, trigger, content, revision_number. UNIQUE(item_id, filename).

Notes:

  • Single migration file: migrations/018_kc_metadata.sql
  • Existing items will have no metadata rows -- they're created on first .kc commit or via PUT /metadata
  • This is a prerequisite for all Phase 1-7 work
Add database migration for all .kc server-side metadata tables as specified in [KC_SERVER.md](docs/KC_SERVER.md) Section 3. **Tables to create:** ### `item_metadata` (Section 3.1) Indexes `silo/manifest.json` and `silo/metadata.json` from .kc files. Primary key on `item_id`. Stores schema_name, tags (TEXT[]), lifecycle_state, fields (JSONB), kc_version, manifest_uuid, silo_instance, revision_hash. Indexes: GIN on tags, B-tree on lifecycle_state, GIN on fields. ### `item_dependencies` (Section 3.2) Indexes `silo/dependencies.json` -- CAD-extracted assembly relationships. Columns: parent_item_id, child_uuid, child_part_number, child_revision, quantity, label, relationship, revision_number. Complements (does not replace) the existing `relationships` table. This is the CAD-authoritative record; `relationships` is the server-authoritative BOM. ### `item_approvals` + `approval_signatures` (Section 3.3) ECO workflow tables. `item_approvals`: item_id, eco_number, state, updated_at, updated_by. `approval_signatures`: approval_id FK, username, role, status, signed_at, comment. ### `item_macros` (Section 3.4) Registers macros from `silo/macros/`. Columns: item_id, filename, trigger, content, revision_number. UNIQUE(item_id, filename). **Notes:** - Single migration file: `migrations/018_kc_metadata.sql` - Existing items will have no metadata rows -- they're created on first .kc commit or via PUT /metadata - This is a prerequisite for all Phase 1-7 work
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
forbes
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: kindred/silo#140
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?