mirror of
https://gitee.com/pnoker/iot-dc3.git
synced 2026-11-01 10:41:52 +08:00
pnokerandClaude Code
4cb3fd6440
The dc3-db aggregate mixed two naming axes and one axis-free module:
infrastructure used dc3-db-r2dbc-{core,runtime,postgres} (with "postgres"
sitting in a layer slot), the domain adapters used dc3-db-postgres-{domain}
(no "r2dbc" at all), and tck had no axis. PostgreSQL-only and R2DBC-only
are properties of the whole aggregate (dc3-db README, docs/db-dialects.md),
so the per-module prefixes carried no discriminating information — the
65 store classes already say R2dbc in their names.
New layout, one dc3-db-{role} pattern, aligned with the common-{domain} /
center-{domain} pairs they serve:
dc3-db-r2dbc-core -> dc3-db-core
dc3-db-r2dbc-runtime -> dc3-db-runtime (absorbs the dialect)
dc3-db-r2dbc-postgres -> (merged into dc3-db-runtime)
dc3-db-postgres-auth -> dc3-db-auth
dc3-db-postgres-manager -> dc3-db-manager
dc3-db-postgres-data -> dc3-db-data
dc3-db-postgres-agentic -> dc3-db-agentic
dc3-db-tck -> unchanged
The dialect module held a single 12-line AutoConfiguration registering
StandardR2dbcDialect("postgres", ...) plus the r2dbc-postgresql driver;
both move into dc3-db-runtime (package io.github.pnoker.db.runtime.dialect,
registered in the runtime AutoConfiguration.imports, driver dependency
transferred). Its six dependents now rely on the runtime they already
pulled in. Java packages rename in step — io.github.pnoker.db.r2dbc.core
-> io.github.pnoker.db.core, io.github.pnoker.db.r2dbc.runtime ->
io.github.pnoker.db.runtime, io.github.pnoker.db.postgres.{auth,manager,
data,agentic} -> io.github.pnoker.db.{auth,manager,data,agentic} — so no
trace of the old axis survives outside git history.
Also fixes the stale module layout in docs/design/relational-r2dbc.md §6
(it still described stores living in dc3-common-*/repository, the
pre-7fde11134 arrangement) and ships migrations/02-schema-fingerprint-
resync.sql for existing volumes still carrying the pre-documentation
fingerprint marker.
Verified: full-reactor compile, dc3-db aggregate tests (-am), all six
service images rebuilt through the multi-stage Dockerfile (container
Maven package), WSL stack recreated with every center healthy, and an
end-to-end login + manager list smoke test through the gateway (JWT
cookie, offset/limit/sort paging).
Co-Authored-By: Claude Code <noreply@anthropic.com>
DC3 DB
dc3-db is the relational persistence layer of IoT DC3. The runtime is PostgreSQL-only and
R2DBC-only: Spring Boot owns one pooled ConnectionFactory, repositories use explicit reactive
ports, and schema fingerprints fail startup when the database contract is wrong. JDBC/MyBatis are
not supported runtime paths.
Modules
| Module | Role |
|---|---|
| dc3-db-core | Framework-neutral PageRequest/OffsetPage/CursorPage, tenant and operation contracts |
| dc3-db-runtime | Spring Boot R2DBC pool, reactive transactions, the single PostgreSQL dialect adapter and the schema-fingerprint startup gate |
| dc3-db-auth | PostgreSQL R2DBC stores for the auth domain ports |
| dc3-db-manager | PostgreSQL R2DBC stores for the manager domain ports |
| dc3-db-data | PostgreSQL R2DBC stores for the data domain ports |
| dc3-db-agentic | PostgreSQL R2DBC stores for the agentic domain ports |
| dc3-db-tck | PostgreSQL Testcontainers contract suite |
Selection
The only supported relational engine is PostgreSQL. The postgres dialect registers
unconditionally from dc3-db-runtime; the runtime rejects startup unless exactly one
R2dbcDialect bean is present.
Changing the database requires a deliberate architecture change, not a runtime compatibility
switch.
Build and verify
mvn -s .mvn/settings.xml -q -f dc3-db/pom.xml -DskipTests compile
mvn -s .mvn/settings.xml -f dc3-db/pom.xml test
python3 dc3/bin/schema_fingerprint.py --check
Dialect conventions and migration notes live in docs/db-dialects.md.