최근 개발 중인 프로젝트에서 soft-delete 기능 및 status를 사용하기 위해 Entity에 status를 추가하고, 그 확인을 위해 @Where 어노테이션을 사용했다.
@Getter
@Entity
@NoArgsConstructor
@Table(name="MEMBER")
@Where(clause = "member_status != 'DISABLED'")
public class Member extends BaseEntity {
@Column(name = "member_id")
@Id @GeneratedValue(strategy = GenerationType.IDENTITY)
private long id;
@Column(name = "username")
private String username;
@Column(name = "password")
private String password;
@Column(name = "member_status")
@Enumerated(EnumType.STRING)
private MemberStatus memberStatus;
}대강 요런 식으로 작업을 했었는데, 결국 깊이 공부하지 않고 쓴 코드에서 문제가 발생하니까 조치가 늦어졌다.
사실 @Where의 기능은 단순하다. 쿼리가 내려갈 때 마지막에 clause를 where에 걸어주는 것.
이를 통해서 status를 빼먹지 않고 관리할 수 있으니까 좋은 거 아니겠어?
같은 안일한 생각을 조심해야 한다는 점을 경계할 수 있는 공부할 수 있는 기회가 되는 그런 모시깽...
문제는, 거꾸로 인스턴스를 만들 때 status를 빼먹어서는 안된다는 점은 주의하지 않았다는 것.
instance를 만들 때 status를 기본으로 넣어주지 않으니 where절에서 계속 걸려서 아무리 쿼리를 집어던져도 망망대해에 던진 유리병 편지마냥 답이 안돌아오더라는 이슈였더랬다.
# 기존
select *
from MEMBER;
# @Where
select *
from MEMBER m
where m.member_status != 'DISABLED';와 같은 식으로 나간 다는 것.
수제 쿼리 바로 쓴거라 틀릴 수 있음
슬픈 사정이 담긴 유리병 편지
우선 DB에 해당 값만 넣었다 뺐다 하면서 확인, 발생 원인을 명확하게 좁혔고, 곧 내 잘못이라는 점만 깨달을 수 있었다.
어우쪽팔려진짜로아휴
아무튼인지 뭔지 감사한건지 어떻게든 교훈을 몇개 얻었는데,
- 일단 코드를 쓰기전에 기능에 대해서 좀 공부를 좀 제발 잘좀 하고 쓰면 좀 오죽 좀 좋겠다 좀
- status와 deleteflag는 구분해서 쓰는게 아무래도 안전할 듯?
사실, 지금까지 몇 가지 작업을 하면서 이런 부분에서 미스를 낸 적은 없었어서 더 좀 충격으로 다가온 점이 있다.
비슷하거나 동일한 기능을 여러 부분에서 구현하면서 이정도의 휴먼 에러를 갈긴 적은 없었어갖고, 아무튼 내 잘못은 아닐 줄로 알았는데... 왜 아니야
중요한건 쿼리에서 조건으로 거는 부분을 당당하게 null로 처박아버리면 대단한 문제가 발생할 수 있다는 점을 이제라도..? 이제야? 알았다는 것??
