여러분 안녕하세요,
셀프 호스터(self-hoster)로서 최근 "디지털 OCD"에 걸렸습니다. 초기 테스트 기간에 삭제했던 카테고리 몇 개와 태그가 있었는데, 데이터베이스에 공백을 남기는 대신, 그 깨끗한 한 자리 ID(예: 카테고리 ID 2, 태그 ID 3)를 되찾고 싶었습니다.
UI에서는 이 기능을 지원하지 않는다는 것을 알기에, Rails 콘솔(./launcher enter app → rails c)에 들어가서 수동으로 모든 것을 다시 조합했습니다. 현재 프론트엔드에서는 모든 것이 보기도 동작도 완벽해 보이지만, 여기 계신 데이터베이스 전문가분들 중 이런 작업을 했을 때 숨겨진 위험이나 장기적인 문제(landmine)가 있을 수 있다고 보시는 분이 있는지 궁금합니다.
제가 수행한 정확하고 상세한 워크플로우는 다음과 같습니다:
1. 기존 ID와 모든 속성을 사용하여 삭제된 카테고리 재생성: 단순히 ID만 강제하는 대신, 레코드가 완전하도록 필수 속성을 제공했습니다.
Ruby
Category.create!(
id: 2,
name: "Site Feedback",
color: "0088CC",
text_color: "FFFFFF",
user_id: -1 # 시스템 사용자
)
2. 원래 주제(topic) 복구 및 카테고리 설명으로 연결:
Ruby
Topic.with_deleted.find(1).recover!
Category.find(2).update!(topic_id: 1)
3. 주제 하위 유형(subtype) 정리 (기본값으로 복원): 다른 기본 카테고리들을 확인해 보니, 설명 주제들이 단순히 nil을 사용한다는 것을 알게 되어 팩토리 상태로 되돌렸습니다.
Ruby
Topic.find(1).update!(subtype: nil)
4. ID 공백을 메우기 위해 기존 태그 일괄 재생성:
Ruby
Tag.create!([
{ id: 3, name: "private-school" },
{ id: 7, name: "tennis" }
])
제 주요 질문: 제 OCD를 충족시키기 위한 것 외에는 실질적인 필요가 없다는 점은 충분히 이해하고 있습니다. 그러나 구조적인 관점에서만 볼 때, .update!와 .create!와 같은 기본 ActiveRecord 메서드가 Discourse의 모든 필요한 콜백(검색 인덱싱, Redis 캐시 업데이트, Sidekiq 작업, 라우팅 등)을 안전하게 트리거하는 것일까요? 아니면 미래의 스키마 마이그레이션을 깨뜨릴 수 있는 중요한 내부 로직을 우회하게 된 것일까요?
호기심을 풀어주셔서 감사합니다!