GROWI Developers Wiki

{{pagename}} - {{sitename}}

# ポイント
## Main と Sub に分けて考える
### Main Operation
#### 責務
ターゲットおよびその子孫の木構造の変化が終了している状態になること(ページツリーには完全に表示できる状態)

### Sub Operation
#### 責務
子孫ページの parent 以外の情報を更新する

### toPath
ページの更新が予約されている場所を表す(ページの引越し先)

### fromPath
ページの移動前の場所を表す(解約予告された物件)

## PageOperation のブロックの理想仕様 (2/15)
## fromPath toPath を計算して不要なブロックを取り除くことができるようにする
### 例
fromPath `/A` => toPath `/B`, fromPath `/B` => toPath `/C` の PageOperation ドキュメントが同時に存在する時、fromPath`/A` => toPath`/C` の時と同じブロックのみで良くなる
### 補足
ページを親から更新していく必要がある

## PageOperationBlock の実装優先度順
1. ページ更新処理をブロックできること
  - toPath をメインにブロックされていれば第一段階クリアとして良いはず
  - fromPath はブロックすべきかどうかが複雑なのでゆっくり考える
3. Sub Operation を Resume できること
  - ここまでをスコープにする場合は Main Operation は正常動作する前提になる
4. Main Operation を Resume できること

# 子孫を含めてページを更新する場合に対象のパス周辺での操作をブロックする

## 要件
- ページの更新をブロックする
    - 広範囲なページの更新処理が頻繁に行われるようになりデータが壊れる可能性が高くなったので、それを防ぐために範囲を被らないようにする仕組みが必要になった

- ページの更新処理を再開する
    - 広範囲な処理は長時間にわたる上、途中で止まった場合にデータ(ページのツリー構造)が壊れる可能性がある。ので、途中でサーバーが落ちたとしても再実行することで必ず処理を最後まで走らせることが必要になった


## 全体設計(Not 確定版)

### ユースケース WIP
- Rename
- Duplicate
- Delete
- DeleteCompletely
- Revert
- NormalizeParent

### モデル設計

```typescript:models/page-operation.ts
interface IPageOperation {
  actionType: PageActionType,
  fromPath: string,
  toPath: string,
  page: IPageForResuming,
  user: IUserForResuming,
  options?: IOptionsForResuming,
  incForUpdatingDescendantCount?: number,
}
```

### Import との兼ね合い
ページコレクションの Import および初期マイグレーションは `メンテナンスモード` という形で全てを止めたい欲が止まらない


## 検索用ワード
resume
Resume
PageOperation
PageOperationBlock
再開
