監査列(created_at / updated_at / created_by / updated_by)の Auditing 機構整備
背景
設計規約 §3.5 で業務テーブルに監査列 4 つを必須化。コーディング規約 §4.1 のサンプルにも 4 列を含めたが、自動投入の実装方針(Spring Data JPA Auditing か手動か)は未決定。
⚠️ 対象外: tenants テーブルは監査列を持たない例外テーブル(ADR-0004 / 設計規約 v1.1 §3.5)。本 Issue の対象から除外する。
作業
- 採用方針を決定(
@CreatedDate / @LastModifiedDate / @CreatedBy / @LastModifiedBy + AuditorAware<Long> を採用するのが第一候補)
@EnableJpaAuditing を Configuration に追加AuditorAware<Long> 実装(現在の TasksPrincipal から user id を返す)
- SaaS Admin (
APP_ADMIN) も JIT プロビジョニングで users 行が確保されている(基本設計書 v1.4.1 §3.2.1 / §4.2 冒頭)ため、特別な分岐は不要。通常の user id をそのまま返してよい
- SaaS Admin は業務テーブルに書き込まない方針(ADR-0004)のため、そもそも本機構が SaaS Admin 経由で発火するケースは想定しない(発火した場合は実装バグの可能性 → 別途検知)
- 既存 JPA Entity に Auditing アノテーション付与(
Task 等、リネーム後の Entity に対して)
- 対象外:
tenants テーブル(上記の例外、ADR-0004 参照)
- 対象外:
users テーブル(既存スキーマ拡張なし、JIT による INSERT のみ。Auditing は適用しない)
- 必要に応じて ADR(想定 ADR-0007 相当)を別途起票するか判断
参照
監査列(created_at / updated_at / created_by / updated_by)の Auditing 機構整備
背景
設計規約 §3.5 で業務テーブルに監査列 4 つを必須化。コーディング規約 §4.1 のサンプルにも 4 列を含めたが、自動投入の実装方針(Spring Data JPA Auditing か手動か)は未決定。
作業
@CreatedDate/@LastModifiedDate/@CreatedBy/@LastModifiedBy+AuditorAware<Long>を採用するのが第一候補)@EnableJpaAuditingを Configuration に追加AuditorAware<Long>実装(現在のTasksPrincipalからuser idを返す)APP_ADMIN) も JIT プロビジョニングでusers行が確保されている(基本設計書 v1.4.1 §3.2.1 / §4.2 冒頭)ため、特別な分岐は不要。通常のuser idをそのまま返してよいTask等、リネーム後の Entity に対して)tenantsテーブル(上記の例外、ADR-0004 参照)usersテーブル(既存スキーマ拡張なし、JIT による INSERT のみ。Auditing は適用しない)参照
tenantsを監査列例外とする決定)