Add Repository<T> interface + ITemporalEntity + IHistoryRepository<T> #8
Loading…
Add table
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Part of a structural refactor: move from per-entity
*Dbclients to a sharedRepository<T>abstraction. This issue lands the interfaces only in webapp-scaffold. No behavior change yet, no concrete implementations, no callers updated.Scope
Add to webapp-scaffold:
Repository<TDto>— pure abstract interface, temporal-agnostic:findByEntityId(entityId)list(filter)save(dto)— generates a random UUID ifentity_idis null on the DTO; otherwise uses the caller-supplied id (mixed allocation policy)softDelete(entityId)ITemporalEntity— DTO mixin/marker requiringentity_id,valid_from,valid_untilIHistoryRepository<TDto>— separate interface forhistory(entityId), only implemented by repositories that wrap temporal entitiesTemporalAt— value type: "live" or a specific point in timeActorContext— placeholder for who is performing the action (used by the scope-guard decorator in the next issue)Out of scope
*Dbcallers in fewo-webappAcceptance
Repository<MockDto>exists, demonstrating the contract without touching SQLDecisions (from planning discussion)
entity_idallocation: mixed — client passes id OR repository allocates a random UUID if nullRepository<T>shape: pure abstract interface (not C++20 concept)IHistoryRepository<T>, not onRepository<T>Agent Evaluation
This issue was drafted as part of the planning thread that produced the parent tracking issue (uwe.admin/fewo-webapp#458). The body above is itself the evaluation; this comment closes the workflow loop.
Feasibility: Trivial — pure header definitions plus an in-memory test fake. No SQL, no controller changes, no fewo-webapp impact.
Impact: Foundational. Phases 2–7 all depend on these interfaces.
Effort: Small.
Recommendation: Accept. No design questions remain (decisions 1–4 are baked into the body).
Agent Evaluation
Feasibility: Medium — interfaces themselves are trivial (~150 LOC of headers + an in-memory test fake). The blocking question is target language: webapp-scaffold today is a TypeScript/npm package (frontend build glue: vite-config, core-fetch, i18n, openapi codegen). It contains no C++. The proposed
Repository<TDto>is a C++ abstraction overoatpp::orm::DbClient. It belongs in a C++ shared library — naturallyoatpp-authkit(the existing header-only C++ companion) or a newoatpp-repopackage — not in the npm frontend scaffold.Impact: High if placed correctly. A composable repository layer is the right shape for the temporal + property-scope cross-cutting concerns the lost-booking incident exposed, and unblocks the 26-entity rollout in fewo-webapp #458. But landing it in webapp-scaffold would put C++ headers next to TypeScript build scripts in a package consumed via npm — an awkward mix that would force fewo-webapp's CMake to depend on a node package, and confuses the repo's stated purpose ("shared frontend build glue").
Effort: Small (~150 LOC) once the host repo is decided.
Recommendation: Needs clarification — pick a host repo before implementation.
Implementation plan (once target is chosen)
Repository.hpp(pure abstract, generic onTDto)ITemporalEntity.hpp(marker requiringentity_id/valid_from/valid_until)IHistoryRepository.hpp(separate interface forhistory(entityId))TemporalAt.hpp(live-or-point-in-time value type)ActorContext.hpp(placeholder for the scope-guard decorator)Repository<MockDto>fake to demonstrate the contract without SQL, gated under the host's existing test-build option.find_packageand link.Decision needed
Check one (edit this comment):
oatpp-repo— Keeps oatpp-authkit narrowly auth/security-focused; introduces a third C++ package to track and version. More boilerplate now.Please go with Option A for now.
Re-evaluation
Responding to owner feedback:
Acknowledged. The C++
Repository<T>layer will land in oatpp-authkit, not webapp-scaffold. This issue (and #9) are effectively redirected — the intent is accepted, but the implementation target moves repos.Implication for tracking: webapp-scaffold #8 / #9 should probably be closed in favour of equivalent tickets in oatpp-authkit. I'll do that as a separate poll action only with explicit owner instruction; for now this issue stays open as the design-discussion record.
Revised implementation plan (against oatpp-authkit)
oatpp-authkit/include/oatpp-authkit/, add a newrepo/subdirectory alongside the existingauth/,db/,dto/,handler/, etc.:repo/Repository.hpp— pure abstracttemplate <class TDto> class RepositorywithfindByEntityId,list,save(mixed UUID allocation),softDelete.repo/ITemporalEntity.hpp— DTO marker requiringentity_id/valid_from/valid_until.repo/IHistoryRepository.hpp— separatehistory(entityId)interface.repo/TemporalAt.hpp—live|at(timestamp)value type.repo/ActorContext.hpp— placeholder DTO for the scope-guard decorator.oatpp-authkit/test/exercising aRepository<MockDto>in-memory fake (matches the existingtest_negotiation.cpp/test_json_serialization.cppstyle — plain executable, REQUIRE macro, no third-party framework).test/CMakeLists.txtandadd_test(NAME repository_interface ...).repo/headers.Updated effort: Small (unchanged — still ~150 LOC).
Updated recommendation: Accept (target now resolved). Ready for implementation when the owner adds
accepted. The pilot uwe.admin/fewo-webapp#457 unblocks once this lands.Decision needed (carried over)
The implementation target above assumes the in-house option lands first. The owner separately raised uwe.admin/webapp-scaffold#10 (optional
IQueryable<T>capability + in-house query AST) — that's a follow-on, not a blocker for this issue.Closed in favour of uwe.admin/oatpp-authkit#7 per the Option A decision (this issue's #8 thread). C++ work belongs in oatpp-authkit, not in this TypeScript scaffold package.