33 lines
1.3 KiB
Markdown
33 lines
1.3 KiB
Markdown
|
|
# Build Event Log (BEL)
|
|
Purpose: Store build events and define views summarizing databuild application state, like partition catalog, build
|
|
status summary, job run statistics, etc.
|
|
|
|
## Architecture
|
|
- Uses [event sourcing](https://martinfowler.com/eaaDev/EventSourcing.html) /
|
|
[CQRS](https://www.wikipedia.org/wiki/cqrs) philosophy.
|
|
- BEL uses only two types of tables:
|
|
- The root event table, with event ID, timestamp, message, event type, and ID fields for related event types.
|
|
- Type-specific event tables (e.g. task even, partition event, build request event, etc).
|
|
- This makes it easy to support multiple backends (SQLite, postgres, and delta tables are supported initially).
|
|
- Exposes an access layer that mediates writes, and which exposes entity-specific repositories for reads.
|
|
|
|
## Correctness Strategy
|
|
- Access layer will evaluate events requested to be written, returning an error if the event is not a correct next.
|
|
state based on the involved component's governing state diagram.
|
|
- Events are versioned, with each versions' schemas stored in [`databuild.proto`](../databuild/databuild.proto).
|
|
|
|
## Write Interface
|
|
See [trait definition](../databuild/event_log/mod.rs).
|
|
|
|
## Read Repositories
|
|
There are repositories for the following entities:
|
|
- Builds
|
|
- Jobs
|
|
- Partitions
|
|
- Tasks
|
|
|
|
Generally the following verbs are available for each:
|
|
- Show
|
|
- List
|
|
- Cancel
|