Which migration stream owns the trigger function every schema uses #124

New Issue

2026-09-21T07:18:37Z

cgalo5758 commented

2026-09-21 07:18:37 +00:00

The question

The function that stamps a row's updated-at column is created by the core stream's first migration, in the public schema, and every stream's tables attach triggers to it. Nothing states that core owns it. Now that each stream keeps its own migration ledger and the integration streams run in any order after core, the question is whether a shared database object belongs in core's migrations, in a copy inside each stream's own schema, or in the code that assembles the migrations before any stream runs.

What depends on the answer

Whether an integration's migrations are self-contained, and where the next object more than one stream needs is created.

Options known so far

Keep it in core and state in the integration guide that core's shared objects are available to every stream.
Give each schema its own copy, so a stream's migrations depend on nothing outside themselves.
Create it in the migration assembly, ahead of every stream, and let core stop owning it.

This is a code-organization question and nothing more: functions are scoped to a database, not to the cluster, so each database gets its own copy and two databases in one cluster never contended for it.

Decided when

The database documentation names the owner of the shared objects and the integration guide says what a new stream may rely on already existing.

Migrated from status/issues.md at b7a0e15

## The question The function that stamps a row's updated-at column is created by the core stream's first migration, in the public schema, and every stream's tables attach triggers to it. Nothing states that core owns it. Now that each stream keeps its own migration ledger and the integration streams run in any order after core, the question is whether a shared database object belongs in core's migrations, in a copy inside each stream's own schema, or in the code that assembles the migrations before any stream runs. ## What depends on the answer Whether an integration's migrations are self-contained, and where the next object more than one stream needs is created. ## Options known so far - Keep it in core and state in the integration guide that core's shared objects are available to every stream. - Give each schema its own copy, so a stream's migrations depend on nothing outside themselves. - Create it in the migration assembly, ahead of every stream, and let core stop owning it. This is a code-organization question and nothing more: functions are scoped to a database, not to the cluster, so each database gets its own copy and two databases in one cluster never contended for it. ## Decided when The database documentation names the owner of the shared objects and the integration guide says what a new stream may rely on already existing. Migrated from status/issues.md at b7a0e15

cgalo5758 added the

kind

design

area/ops labels 2026-09-21 07:18:37 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: wiki-cafe/member-console#124