ores.database

Table of Contents

1. Diagram

ores.database component diagram

Figure 1: ores.database

2. Summary

ores.database is the shared PostgreSQL access layer used by every domain service. It provides a connection pool (tenant_aware_pool), tenant and party context management, bitemporal CRUD operations, repository base helpers, and the mapper and exception scaffolding the generated repositories build on. It also exposes a health_monitor and a postgres_listener_service for LISTEN/NOTIFY integration. All persistence code in domain services builds on this library.

The component owns no codegen entity models. It is hand-written infrastructure, and every type it exposes stays below the audit, history and eventing stacks it would otherwise have to link. The ores_database_info_tbl table lives in the SQL technical space under projects/ores.sql.

3. Inputs

  • PostgreSQL connection string from service configuration.
  • Tenant and party identifiers set per request for row-level security.

4. Outputs

  • Pooled libpqxx connections scoped to tenant/party context.
  • Bitemporal entity CRUD results with version-conflict detection.

5. Entry points

  • include/ores.database/domain/ — database_options, context, tenant_aware_pool.
  • include/ores.database/repository/ — bitemporal operations, mapper helpers.
  • include/ores.database/service/ — health_monitor, postgres_listener_service, tenant_context, party_context.
  • include/ores.database/config/ — database_configuration parsing.

6. Dependencies

  • libpqxx — PostgreSQL C++ client.
  • ores.logging — structured logging.

7. Entity modules

None. The component has no codegen entity models.

8. See also

Emacs 29.3 (Org mode 9.6.15)