222 lines
7.4 KiB
Markdown
222 lines
7.4 KiB
Markdown
# Soft Delete 예시
|
|
|
|
## 좋은 예시
|
|
|
|
### 예시 1. 기본 soft delete 컬럼은 deleted_at으로 둔다
|
|
|
|
```sql
|
|
CREATE TABLE auth.users (
|
|
id bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
|
|
email text NOT NULL,
|
|
display_name text NOT NULL,
|
|
deleted_at timestamp with time zone
|
|
);
|
|
```
|
|
|
|
**좋은 이유:**
|
|
|
|
- soft delete를 삭제 시점으로 표현한다
|
|
- active row 조건이 `deleted_at IS NULL`로 단순해진다
|
|
- boolean-only보다 운영 추적성이 좋다
|
|
|
|
Hibernate는 TIMESTAMP soft delete 전략이 삭제된 시점을 추적한다고 설명한다. 프로젝트 기본값을 `deleted_at`으로 두는 것은 그 전략과 잘 맞는다.
|
|
|
|
### 예시 2. active row uniqueness는 partial unique index로 강제한다
|
|
|
|
```sql
|
|
CREATE UNIQUE INDEX uq_users__email__active
|
|
ON auth.users (email)
|
|
WHERE deleted_at IS NULL;
|
|
```
|
|
|
|
**좋은 이유:**
|
|
|
|
- active row 사이에서만 이메일 중복을 막는다
|
|
- soft-deleted row는 uniqueness 대상에서 제외할 수 있다
|
|
- PostgreSQL이 공식적으로 지원하는 부분집합 uniqueness 패턴이다
|
|
|
|
PostgreSQL은 일부 row에만 적용되는 uniqueness restriction은 unique constraint가 아니라 unique partial index로 표현해야 한다고 설명한다.
|
|
|
|
### 예시 3. soft delete는 DELETE가 아니라 UPDATE로 수행한다
|
|
|
|
```sql
|
|
UPDATE auth.users
|
|
SET deleted_at = current_timestamp
|
|
WHERE id = :userId
|
|
AND deleted_at IS NULL;
|
|
```
|
|
|
|
**좋은 이유:**
|
|
|
|
- soft delete를 상태 전이로 표현한다
|
|
- 이미 삭제된 row에 대한 중복 처리도 막기 쉽다
|
|
- 일반 삭제와 물리 삭제를 분리하기 좋다
|
|
|
|
Hibernate는 soft delete를 실제 삭제 대신 indicator column update로 설명한다.
|
|
|
|
### 예시 4. Hibernate를 쓴다면 TIMESTAMP soft delete를 공식 기능으로 쓸 수 있다
|
|
|
|
```java
|
|
@Entity
|
|
@SoftDelete(strategy = SoftDeleteType.TIMESTAMP, columnName = "deleted_at")
|
|
@Table(name = "users", schema = "auth")
|
|
public class User {
|
|
@Id
|
|
private Long id;
|
|
}
|
|
```
|
|
|
|
**좋은 이유:**
|
|
|
|
- Hibernate의 공식 soft delete 기능을 사용한다
|
|
- TIMESTAMP 전략이 삭제 시점을 추적한다
|
|
- 컬럼 이름을 프로젝트 표준인 `deleted_at`으로 맞출 수 있다
|
|
|
|
Hibernate는 `@SoftDelete`가 TIMESTAMP 전략을 지원하고, indicator column 이름은 `columnName`으로 정의할 수 있다고 설명한다.
|
|
|
|
### 예시 5. @ManyToMany / @ElementCollection join table에는 soft delete를 제한적으로 적용할 수 있다
|
|
|
|
```java
|
|
@ManyToMany
|
|
@JoinTable(
|
|
name = "user_roles",
|
|
joinColumns = @JoinColumn(name = "user_id"),
|
|
inverseJoinColumns = @JoinColumn(name = "role_id")
|
|
)
|
|
@SoftDelete(strategy = SoftDeleteType.TIMESTAMP, columnName = "deleted_at")
|
|
private Set<Role> roles;
|
|
```
|
|
|
|
**좋은 이유:**
|
|
|
|
- Hibernate 공식 지원 범위 안에서 join table row를 soft delete할 수 있다
|
|
- 관계 row의 논리 삭제가 필요한 경우에만 제한적으로 쓸 수 있다
|
|
- 엔티티 자체 soft delete와 컬렉션 테이블 soft delete를 구분한다
|
|
|
|
Hibernate는 `@SoftDelete`를 `@ElementCollection`과 `@ManyToMany` collection table에 적용할 수 있다고 설명한다.
|
|
|
|
### 예시 6. soft delete와 bulk purge를 분리한다
|
|
|
|
```java
|
|
public interface UserRepository extends JpaRepository<User, Long> {
|
|
|
|
@Modifying
|
|
@Query("""
|
|
delete from User u
|
|
where u.deletedAt < :cutoff
|
|
""")
|
|
int purgeDeletedBefore(@Param("cutoff") OffsetDateTime cutoff);
|
|
}
|
|
```
|
|
|
|
**좋은 이유:**
|
|
|
|
- 일반 삭제는 soft delete 경로로 두고, 오래된 삭제 row 정리는 purge 전용 경로로 분리한다
|
|
- bulk delete가 direct database delete임을 명시적으로 드러낸다
|
|
- soft delete와 physical purge를 같은 경로로 섞지 않는다
|
|
|
|
Spring Data JPA는 JPQL/Criteria bulk delete가 DB 직접 delete로 매핑되고 persistence context를 동기화하지 않는다고 설명한다. 이런 방식은 purge 전용 경로에서만 명시적으로 쓰는 편이 안전하다.
|
|
|
|
## 나쁜 예시
|
|
|
|
### 예시 1. soft delete 컬럼은 있지만 기본 조회에서 빼지 않는다
|
|
|
|
```sql
|
|
SELECT id, email
|
|
FROM auth.users
|
|
ORDER BY id DESC;
|
|
```
|
|
|
|
**나쁜 이유:**
|
|
|
|
- 삭제 row가 일반 조회에 섞인다
|
|
- soft delete가 조회 계약으로 완성되지 않는다
|
|
- active-row partial index와도 잘 맞지 않는다
|
|
|
|
PostgreSQL은 partial index가 query WHERE 조건이 predicate를 함의할 때만 사용될 수 있다고 설명한다. active-row 조회는 predicate를 명시적으로 포함해야 한다.
|
|
|
|
### 예시 2. active-only uniqueness를 일반 UNIQUE로 둔다
|
|
|
|
```sql
|
|
CREATE TABLE auth.users (
|
|
id bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
|
|
email text NOT NULL UNIQUE,
|
|
deleted_at timestamp with time zone
|
|
);
|
|
```
|
|
|
|
**나쁜 이유:**
|
|
|
|
- soft-deleted row까지 포함해 테이블 전체에서 email 중복을 막아 버린다
|
|
- "삭제된 이메일은 다시 쓸 수 있다"는 정책을 표현할 수 없다
|
|
- active subset uniqueness가 아니라 전체-table uniqueness다
|
|
|
|
PostgreSQL은 일부 row에만 적용되는 uniqueness restriction은 unique constraint로 쓸 수 없고, partial unique index로 표현해야 한다고 설명한다.
|
|
|
|
### 예시 3. partial unique index natural key를 FK target으로 사용하려고 한다
|
|
|
|
```sql
|
|
CREATE UNIQUE INDEX uq_users__email__active
|
|
ON auth.users (email)
|
|
WHERE deleted_at IS NULL;
|
|
|
|
CREATE TABLE auth.login_audit (
|
|
user_email text REFERENCES auth.users(email)
|
|
);
|
|
```
|
|
|
|
**나쁜 이유:**
|
|
|
|
- FK 대상은 non-partial unique index 또는 PK/UNIQUE 제약이어야 한다
|
|
- active-row partial unique index는 FK target 자격이 없다
|
|
- soft delete와 natural key 참조를 섞으면 설계가 불안정해진다
|
|
|
|
PostgreSQL은 FK 참조 대상이 non-deferrable unique/primary key 제약 또는 non-partial unique index여야 한다고 설명한다.
|
|
|
|
### 예시 4. @OneToMany 컬렉션에 @SoftDelete를 붙인다
|
|
|
|
```java
|
|
@OneToMany(mappedBy = "user")
|
|
@SoftDelete(strategy = SoftDeleteType.TIMESTAMP, columnName = "deleted_at")
|
|
private List<Session> sessions;
|
|
```
|
|
|
|
**나쁜 이유:**
|
|
|
|
- Hibernate 공식 지원 범위가 아니다
|
|
- `@OneToMany`에 `@SoftDelete`를 붙이면 예외가 난다
|
|
- 자식 엔티티 자체를 soft delete해야 한다
|
|
|
|
Hibernate는 `@OneToMany` association에 `@SoftDelete`를 붙이면 예외를 던진다고 설명한다.
|
|
|
|
### 예시 5. soft-deletable 엔티티를 batch delete로 지운다
|
|
|
|
```java
|
|
userRepository.deleteAllInBatch(users);
|
|
```
|
|
|
|
**나쁜 이유:**
|
|
|
|
- 단일 query physical delete가 일어난다
|
|
- persistence context가 DB와 동기화되지 않을 수 있다
|
|
- JPA cascade semantics와 lifecycle events도 존중되지 않는다
|
|
- soft delete semantics를 우회할 위험이 크다
|
|
|
|
Spring Data JPA는 `deleteAllInBatch(Iterable)`가 단일 query를 만들고, first level cache와 DB를 out of sync 상태로 만들 수 있으며, JPA cascade와 lifecycle event를 존중하지 않는다고 설명한다.
|
|
|
|
### 예시 6. restore를 uniqueness 검증 없이 수행한다
|
|
|
|
```sql
|
|
UPDATE auth.users
|
|
SET deleted_at = NULL
|
|
WHERE id = :userId;
|
|
```
|
|
|
|
**나쁜 이유:**
|
|
|
|
- 같은 이메일을 가진 다른 active row가 이미 있으면 active subset uniqueness를 깨뜨릴 수 있다
|
|
- restore는 단순 null 복원이 아니라 active set에 다시 들어가는 상태 전이다
|
|
- partial unique index와 충돌 가능성을 고려해야 한다
|
|
|
|
PostgreSQL unique partial index는 predicate를 만족하는 row subset 안에서 uniqueness를 강제한다. restore는 그 subset으로 다시 들어가는 행위다.
|