26ff8d9b4f
Set up repository with legacy .NET Framework 4.8 source (OLD/), new .NET 10 Blazor solution (NEW/), OpenSpec specifications, documentation, and project configuration.
2.6 KiB
2.6 KiB
Database Schema - Migration Implementation
ADDED Requirements
Requirement: Date/time column types
The system SHALL use DATETIME2(7) for all date/time columns instead of legacy DATETIME.
Rationale
- DATETIME2(7) provides nanosecond precision vs millisecond for DATETIME
- Larger date range (0001-01-01 to 9999-12-31)
- Recommended for all new SQL Server development
- Compatible with .NET DateTimeOffset
Affected Tables
All tables with date/time columns:
- Search (SubmitDT, StartDT, EndDT)
- DataUpdate (UpdateDT)
- WorkOrder_Curr/Hist (various date columns)
- WorkOrderStep_Curr/Hist (LastUpdateDT)
- WorkOrderTime_Curr/Hist (GlDate, LastUpdateDT)
- And all other tables with DATETIME columns
Scenario: Date precision preserved
- WHEN a datetime value is stored with sub-millisecond precision
- THEN the full precision is preserved in DATETIME2(7) columns
ADDED Requirements
Requirement: DbUp migration scripts
The system SHALL use DbUp migration scripts to create and maintain the database schema.
Migration Script Organization
- Scripts SHALL be numbered sequentially (NNN_Description.sql)
- Scripts SHALL be embedded as resources in JdeScoping.Database assembly
- Scripts SHALL execute in dependency order (tables → views → types → procedures)
Script Numbering Ranges
| Range | Category |
|---|---|
| 001-025 | Tables |
| 026-032 | Views |
| 033-039 | Table-valued parameter types |
| 040-043 | Stored procedures |
| 044+ | Functions |
Scenario: Fresh database deployment
- WHEN the application starts against an empty database
- THEN DbUp creates all 44 database objects in dependency order
- AND the SchemaVersions table records each applied migration
Scenario: Incremental migration
- WHEN the application starts against a database with some migrations applied
- THEN DbUp applies only new migrations not in SchemaVersions
- AND existing data is preserved
Requirement: Migration idempotency
The system SHALL ensure migration scripts are idempotent for safe re-execution.
Idempotency Patterns
- Tables: Use
IF NOT EXISTSchecks - Views: Use
CREATE OR ALTER VIEW - Types: Check sys.types before creation
- Procedures: Use
CREATE OR ALTER PROCEDURE - Functions: Use
CREATE OR ALTER FUNCTION
Scenario: Re-run migration on existing database
- WHEN a migration script runs against a database where the object already exists
- THEN the script completes without error
- AND the object definition matches the script