Model tasks and company scope

Before you start: complete Understand workspaces and deployment roles, or make sure you can pass its checkpoint.

Replace the scaffold model#

In modules/learn_api.ts, replace the scaffold's Note model with the Todo declaration below. Keep it inside the module's models map:

// File: learn_api/modules/learn_api.ts
// Inside defineModule({ models: { ... } })
Todo: {
  scope: 'company',
  fields: { id: 'id', title: 'text', done: 'bool' },
},

Update the list function's effect and table reference from learn_api.Note to learn_api.Todo. Build and run ket check. The completed download already contains this change.

Understand the field choices#

id is a record identity. title is text owned by the user. done is a boolean, not the strings “yes” and “no.” Optional fields use the framework's optional type syntax, for example text?. The function layer will decide which fields a caller may supply and which are generated by the server.

scope: 'company' adds a data access boundary. The active context determines the company for writes and the companies visible to reads. A browser-supplied JSON property named company is not a substitute for establishing that context.

Inspect rather than guessing#

# Run from: learn_api
npm run build
npx ket manifest --deployment learn_api --workspace dist/ket.workspace.js
npx ket types --deployment learn_api --workspace dist/ket.workspace.js

Find the generated field contract. Keep a note of the model key because effects, queries, relations and report targets reference that stable identity.

Add one schema exercise#

In a disposable copy, add an optional description: 'text?' field. Build and start the local app so the development migration path can apply it. Do not assume editing TypeScript modifies an already-running production database. The migrations lesson makes that process explicit.

Relations and indexes also belong to the schema. Choose them from query needs: a list filtered by owner and status has different access patterns from lookup by ID. Avoid adding an index for every field without a concrete read pattern.

Think about data classification#

Before adding email, addresses or other identifying information, decide what the field contains and declare the relevant classification contract. Even a small application benefits from knowing which data must not appear in logs or broad exports.

Checkpoint#

The composed model has exactly the intended fields and company scope. You can distinguish a record ID, a company context, and a user-editable field.

Practice on your own#

Propose an optional due date and one useful index. Explain the read query that would benefit from the index before adding it.

Reference#

For the complete API contract, read Models.