Data Model

As a rule, plugins should be self-contained within their own tables. For reading core data (employees, departments, etc.), see Core API Integration (direct DB access is not allowed).

CRUD with niyase.data

Operate on the tables declared in the manifest's tables[] through the bridge.

const niyase = useNiyase();

await niyase.data.list("task", { limit: 50 }); // → { items, nextCursor? }
await niyase.data.get("task", id);
await niyase.data.create("task", { title: "現場A" });
await niyase.data.update("task", id, { status: "DONE" });
await niyase.data.remove("task", id); // soft delete

Internally this calls /nplg/:pluginId/:table (authorized by the user session + the current space).

Physical table-name convention

Each environment's loader expands the manifest's logical table name into the following:

plg_<scope>_<name>_<table>

Example: task of @your-org/tasks → plg_your_org_tasks_task (Hyphens in scope / name are converted to underscores. Stay within Postgres's 63-character limit.)

Auto-added columns

The loader adds the following automatically, so you do not need to write them in columns:

• id (primary key)
• workspace_id
• created_at / updated_at
• deleted_at (soft delete)

Master data vs. transactional tables

Design separately for the initial data (master data) seeded by an industry preset (industryPresets[].seedData) and the transactions (business records) that users create:

• Master data: task_status / category, etc. — seeded via seedData, user-editable
• Transactional: task / quote, etc. — records users create

Column types

Declare with three platform-independent types (the loader translates them to each DB's physical type):

Type	Use
TEXT	Strings, dates (ISO), enums
INTEGER	Integers, amounts (manage yen as integers)
REAL	Decimals