AaronPo/the-biergarten-app
1
0
Fork 0
mirror of https://github.com/aaronpo97/the-biergarten-app.git synced 2026-10-14 17:54:42 +00:00
Code Issues Packages Projects Releases Wiki Activity

Update docs to reflect per-table DDL scripts and schema.dbml from #251 (#252)

Browse Source
This commit is contained in:
Aaron Po
2026-08-27 01:02:58 -04:00
committed by GitHub
parent fcee0f9213
commit 92a30b11db
2 changed files with 20 additions and 10 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
docs/architecture.md
View File

@@ -476,12 +476,16 @@ For the table-by-table schema and the custom SQL error code scheme, see
``` ```
scripts/ scripts/
└── 01-schema/ └── 01-schema/
└── schema.sql # full table/index/constraint definitions ├── 01-UserAccount.sql
├── 02-Photo.sql
├── ...
└── 16-BeerPostComment.sql # one script per CREATE TABLE
``` ```
Currently the whole schema is a single versioned script. As the schema evolves, Each table has its own script, numbered so a table's foreign keys always point
new numbered scripts get added alongside it rather than editing `schema.sql` in at an earlier-numbered script. As the schema evolves, new numbered scripts get
place, so DbUp's already-applied tracking stays valid. added rather than editing an existing one in place, so DbUp's already-applied
tracking stays valid.
### Data seeding ### Data seeding

18
docs/website/database.md
View File

@@ -6,12 +6,17 @@ convention. For the vertical-slice code that talks to this schema, see
## Schema ## Schema
The full schema lives in one script: The full schema lives under
`web/backend/Database/Database.Migrations/scripts/01-schema/schema.sql`, run by `web/backend/Database/Database.Migrations/scripts/01-schema/`, one numbered
script per table (`01-UserAccount.sql`, `02-Photo.sql`, ...), run in order by
`Database.Migrations` (DbUp) on startup. Each table is queried directly by the `Database.Migrations` (DbUp) on startup. Each table is queried directly by the
owning feature slice's repository (see owning feature slice's repository (see
[Direct SQL via Dapper/ADO.NET](../architecture.md#direct-sql-via-dapperadonet)). [Direct SQL via Dapper/ADO.NET](../architecture.md#direct-sql-via-dapperadonet)).
A generated DBML copy of the schema (for import into a diagramming tool such
as dbdiagram.io) lives at
`web/backend/Database/Database.Migrations/schema.dbml`.
All tables use a `UNIQUEIDENTIFIER` primary key defaulting to `NEWID()`, and All tables use a `UNIQUEIDENTIFIER` primary key defaulting to `NEWID()`, and
most carry a `RowVersion ROWVERSION` column used for optimistic concurrency on most carry a `RowVersion ROWVERSION` column used for optimistic concurrency on
updates (`UPDATE ... WHERE ... AND RowVersion = @RowVersion`). updates (`UPDATE ... WHERE ... AND RowVersion = @RowVersion`).
@@ -50,10 +55,11 @@ repository or seed data yet:
**Tool**: DbUp, run by the `Database.Migrations` project/container. **Tool**: DbUp, run by the `Database.Migrations` project/container.
Scripts live under `scripts/`, applied in order and tracked so a script never Scripts live under `scripts/`, applied in order and tracked so a script never
re-runs once it has succeeded. Today that's a single `01-schema/schema.sql`. re-runs once it has succeeded. Today that's `01-schema/`, with one script per
When the schema needs to change, add a new numbered script rather than editing table, numbered so a table's foreign keys always point at an earlier-numbered
`schema.sql` in place — DbUp's tracking is per-script, so editing an script. When the schema needs to change, add a new numbered script rather than
already-applied script means it won't re-run against existing databases. editing an existing one in place — DbUp's tracking is per-script, so editing
an already-applied script means it won't re-run against existing databases.
## Data seeding ## Data seeding