# バッチ設計書 12-cleanup_old_data_outputs

## 概要

本ドキュメントは、InvenTreeシステムにおける古いデータ出力ファイルのクリーンアップバッチ処理について記述します。このバッチは、5日以上経過した古いデータ出力エントリをデータベースおよび関連ファイルから削除し、ストレージの効率的な利用を維持します。

### 本バッチの処理概要

**業務上の目的・背景**：InvenTreeでは、ユーザーがデータのエクスポートやレポート生成を行った際、出力結果がDataOutputモデルとして保存されます。これらの出力データは一時的なものであり、長期間保存する必要がありません。ストレージ容量の節約とシステムパフォーマンスの維持のため、古いデータ出力を定期的に削除する必要があります。本バッチは、この課題を自動的に解決します。

**バッチの実行タイミング**：日次（毎日1回）。Django-Qスケジューラによりスケジュールされ、バックグラウンドワーカーによって実行されます。

**主要な処理内容**：
1. 現在日付から5日前の日付を計算
2. DataOutputテーブルから作成日が5日以上前のレコードを検索
3. 各レコードを個別に削除（関連ファイルも同時に削除）
4. 削除処理完了

**前後の処理との関連**：本バッチは独立して動作し、他のバッチとの直接的な依存関係はありません。データエクスポート機能やレポート生成機能の後続処理として位置付けられます。

**影響範囲**：common_dataoutputテーブルおよび関連するファイルストレージに影響します。5日以内のデータ出力には影響しません。

## バッチ種別

データクレンジング

## 実行スケジュール

| 項目 | 内容 |
|-----|------|
| 実行頻度 | 日次 |
| 実行時刻 | Django-Qスケジューラによる自動実行 |
| 実行曜日 | 毎日 |
| 実行日 | - |
| トリガー | cron（Django-Qスケジューラ） |

## 実行条件

### 前提条件

| 条件 | 説明 |
|-----|------|
| Django-Qワーカー稼働中 | バックグラウンドワーカーが稼働している必要がある |
| データベース接続可能 | DataOutputテーブルへのアクセスが可能であること |
| ファイルシステムアクセス可能 | 出力ファイルの削除が可能であること |

### 実行可否判定

- スケジューラに登録されたタイミングで自動実行
- 特別な実行可否判定ロジックは存在しない

## 入力仕様

### 入力パラメータ

| パラメータ名 | 型 | 必須 | デフォルト値 | 説明 |
|-------------|-----|-----|-------------|------|
| なし | - | - | - | 本バッチはパラメータを取らない |

### 入力データソース

| データソース | 形式 | 説明 |
|-------------|------|------|
| common_dataoutput | DB | データ出力テーブル |

## 出力仕様

### 出力データ

| 出力先 | 形式 | 説明 |
|-------|------|------|
| なし | - | ログ出力のみ |

### 出力ファイル仕様

ファイル出力なし

## 処理フロー

### 処理シーケンス

```
1. バッチ開始
   └─ 処理開始
2. 閾値日付計算
   └─ current_date() - 5日 = threshold
3. 対象レコード検索
   └─ DataOutput.objects.filter(created__lte=threshold)
4. 個別削除処理
   └─ 各outputに対してoutput.delete()を実行
   └─ モデルのdelete()により関連ファイルも削除
5. バッチ終了
```

### フローチャート

```mermaid
flowchart TD
    A[バッチ開始] --> B[閾値日付計算: 現在日-5日]
    B --> C[5日以上前のDataOutput検索]
    C --> D{対象レコード存在?}
    D -->|あり| E[レコードを1件ずつ削除]
    E --> F[関連ファイルも削除]
    F --> G{次のレコード?}
    G -->|あり| E
    G -->|なし| H[バッチ終了]
    D -->|なし| H
```

## データベース操作仕様

### 操作別データベース影響一覧

| 処理 | 対象テーブル | 操作種別 | 概要 |
|-----|-------------|---------|------|
| 古いデータ出力削除 | common_dataoutput | DELETE | 5日以上経過したレコードの削除 |

### テーブル別操作詳細

#### common_dataoutput

| 操作 | 項目（カラム名） | 更新値・取得条件 | 備考 |
|-----|-----------------|-----------------|------|
| SELECT | created | created <= threshold | 削除対象の検索 |
| DELETE | - | created <= threshold | レコード削除、関連ファイルも削除 |

## エラー処理

### エラーケース一覧

| エラーコード | エラー種別 | 発生条件 | 対処方法 |
|------------|----------|---------|---------|
| - | OperationalError | データベース接続エラー | データベース接続を確認 |
| - | FileNotFoundError | 関連ファイルが存在しない | 警告ログを出力して継続 |
| - | PermissionError | ファイル削除権限がない | ファイル権限を確認 |

### リトライ仕様

| 項目 | 内容 |
|-----|------|
| リトライ回数 | Django-Qのデフォルト設定に依存 |
| リトライ間隔 | Django-Qのデフォルト設定に依存 |
| リトライ対象エラー | 一時的なデータベースエラー |

### 障害時対応

1. ログを確認してエラー原因を特定
2. データベース接続およびファイルシステム権限を確認
3. 必要に応じて手動で再実行

## トランザクション仕様

| 項目 | 内容 |
|-----|------|
| トランザクション範囲 | レコード単位 |
| コミットタイミング | 各レコード削除完了時 |
| ロールバック条件 | 個別レコード削除失敗時（他のレコードには影響しない） |

## パフォーマンス要件

| 項目 | 内容 |
|-----|------|
| 想定処理件数 | 数十〜数百件/日 |
| 目標処理時間 | 5分以内 |
| メモリ使用量上限 | 特に制限なし |

## 排他制御

- 同時実行可能（各レコードを個別に削除するため）
- ただし、通常は日次1回の実行のため同時実行は想定しない

## ログ出力

| ログ種別 | 出力タイミング | 出力内容 |
|---------|--------------|---------|
| 進捗ログ | 各レコード削除時 | 削除されたデータ出力の情報（暗黙的） |

## 監視・アラート

| 監視項目 | 閾値 | アラート先 |
|---------|-----|----------|
| タスク失敗 | 1回 | システム管理者 |
| 処理時間 | 10分超過 | システム管理者 |

## 備考

- レコードを個別に削除することで、関連ファイルも確実に削除される設計
- DataOutputモデルのdelete()メソッドで関連ファイル削除が実装されている前提
- 5日という保持期間はハードコードされており、設定変更不可
- OpenTelemetryによるトレーシングに対応
