docs: approve Ent and pgx data access
This commit is contained in:
@@ -150,10 +150,11 @@ Resolved: use a capability-oriented modular monolith, with lightweight ports/ada
|
||||
|
||||
Resolved: use manual constructor injection with explicit wiring at thin `cmd/` composition roots. See ADR 0002.
|
||||
|
||||
Resolved: use Ent for application persistence/modeling and pgx/PostgreSQL `COPY` for streamed bulk-ingestion staging. Migrations are explicit and versioned; production startup never performs automatic schema changes. See ADR 0003.
|
||||
|
||||
Remaining approval gates:
|
||||
|
||||
1. PostgreSQL access stack: ORM choice plus a bulk-ingest path suitable for 2.2M+ rows.
|
||||
2. Source timestamp timezone and daylight-saving assumptions.
|
||||
3. Whether `payer_card_key` must be retained, irreversibly transformed, or omitted after derived analytics.
|
||||
4. Minimum cohort size and suppression policy for peer benchmarks.
|
||||
5. Physical partitioning/materialization strategy, which must follow measured query needs rather than the logical ERD alone.
|
||||
1. Source timestamp timezone and daylight-saving assumptions.
|
||||
2. Whether `payer_card_key` must be retained, irreversibly transformed, or omitted after derived analytics.
|
||||
3. Minimum cohort size and suppression policy for peer benchmarks.
|
||||
4. Physical partitioning/materialization strategy, which must follow measured query needs rather than the logical ERD alone.
|
||||
|
||||
Reference in New Issue
Block a user