ores.reporting.report_trigger_event
Table of Contents
One row per report trigger. A trigger is how a run is admitted, and it is of two types: a person asks for the run now, or a schedule asks for it later. The scheduler does not write this table. Its job publishes a trigger event, and the reporting service records the trigger here and admits the run, so both types reach the same handler and differ only in the payload.
The rows are append-only, so the model states :current_state:: an event is a
fact about an instant, and the bi-temporal pair has no meaning on it. A
current-state immutable table has no audit tail, so the actor and the time are
columns of its own and there is no version and no validity window. The table is
plain, not a hypertable: ores.iam.auth_event is one because logins are high
volume, and triggers are a handful a day.
1. Flags
2. Columns
2.1. id
UUID uniquely identifying this trigger.
2.2. report_definition_id
The definition this trigger runs.
2.3. trigger_type
What asked for the run: on_demand or scheduled. Refers to
ores_reporting_report_trigger_types_tbl.
2.4. scheduler_job_id
The scheduler job that fired, when the type is scheduled. The scheduler owns that job, so this is a soft foreign key and not a database constraint. It is a uuid because the job definition's key is one, and because the same reference on ores.reporting.report_definition is spelled scheduler_job_id and typed uuid.
2.5. schedule_job_run_id
The scheduler firing that produced this trigger, when the type is scheduled. Null for an on-demand trigger, which no firing produced.
2.6. triggered_by
The person who asked for the run. For a scheduled trigger it is the person whose consent the schedule acts under.
2.7. triggered_at
When the trigger was recorded.
2.8. party_id
The party the run acts in.
3. SQL
3.1. Flags
3.2. Checks
| expression |
|---|
| "trigger_type" <> 'scheduled' or "scheduler_job_id" is not null |
4. Foreign keys
4.1. trigger_type
Report trigger types are a system-wide lookup seeded for the system tenant only, so the check reads that tenant whatever tenant owns the trigger.
4.2. scheduler_job_id
The scheduler owns its job definitions, so this is a soft foreign key validated here rather than a database constraint. Its table is hand-written and carries no validity window, so the check names its id alone. The key is a uuid, which is what the scheduler declares its job definition's id to be.
4.3. schedule_job_run_id
The scheduler owns its job instances, so this is a soft foreign key validated here rather than a database constraint. Its table is hand-written and carries no validity window, so the check names its id alone. The key is a bigint, which is what the scheduler declares, so this reference is typed bigint and not uuid.
5. C++
5.1. Flags
5.2. Repository
5.3. Domain includes
#include <chrono> #include <cstdint> #include <optional> #include <string> #include <boost/uuid/uuid.hpp>
5.4. Entity includes
#include <chrono> #include <cstdint> #include <optional> #include <string> #include <boost/uuid/uuid.hpp>
5.5. Conventions
6. Physical space
The table is internal: the trigger handler that writes it is hand-written, so only the data layer and the SQL schema are generated here.
| Address | Enabled |
|---|---|
| ores.cpp.service | false |
| ores.cpp.protocol | false |
| ores.cpp.nats-handler | false |
| ores.cpp.nats-sub-registrar | false |
| ores.cpp.nats-event-registrar | false |
| ores.cpp.nats-eventing | false |
| ores.cpp.nats-event-cache | false |
| ores.cpp.history-provider-registrar | false |
| ores.cpp.presentation | false |
| ores.cpp.eventing-integration-test | false |
| ores.cpp.shell-command | false |
| ores.sql.schema.notify_trigger | false |
| ores.sql.schema.notify_trigger_drop | false |
| ores.ts.protocol | false |
| ores.ts.domain | false |
7. See also
- ores.reporting — component group overview.