마이그레이션 원본이 살아 있었다

구 LMS 의 API 로 들어온 과정 식별자를 신 Moodle 의 마스터 과정으로 이어야 했다. 치환 지점은 legacy_course_route 함수 하나였다.

Open Table of contents

증상 — 치환이 안 됐다
원인 — 원본이 남아 있었다
제약 — 없는 부모 관계
판단 기준 — 매핑은 별도 표에
주의 — 플래그가 아니라 권한
결과 — 단일 진입점과 확인 순서
정리

증상 — 치환이 안 됐다

치환하는 자리는 이랬다.

// local/dlp/lib/legacy_route.php
$course = dlp_course::find_by_legacy_code($id);

if (!$course->is_master) {
    $id = $course->parent()->legacy_code;   // 부모(마스터)로 치환
}

is_master 가 아니면 parent 를 따라가 마스터의 식별자로 바꾼다.

그런데 일부 legacy_code 는 치환이 안 됐다. 그 과정들을 조회했다.

SELECT id, version, is_master, parent_course_id
  FROM local_dlp_courses WHERE legacy_code = ?;

version           v1-migrated
is_master         0
parent_course_id  NULL

is_master 도 0이고 parent_course_id 도 비어 있었다.

원인 — 원본이 남아 있었다

version 에 찍힌 v1-migrated 가 무엇인지 봤다.

[예상]  마이그레이션 = 원본을 신버전으로 변환
[실제]  원본은 남기고 별도로 신버전 생성

마이그레이션이 원본을 지우지 않고 version 만 바꿔 둔 것이었다.

새 행을 만들고 옛 행을 지우지 않았으니 두 행이 모두 살아 있는 상태다. 없어서 못 잇는 것이 아니라 있는데도 안 이어지고 있었다.

제약 — 없는 부모 관계

v1-migrated 행과 마스터 사이에 관계가 없었다.

[신버전 마스터]  ←  차수 과정들이 parent 로 연결
[마이그레이션 원본]  ←  아무 관계 없음

parent_course_id 가 비어 있으니 치환 로직이 탈 수가 없다.

일반 차수 과정은 부모 관계로 마스터를 찾지만 마이그레이션 원본에는 그 길이 아예 없었다. 부모 관계만 보면 원본은 영원히 안 이어진다.

판단 기준 — 매핑은 별도 표에

그러면 원본과 마스터를 잇는 정보가 어디 있는지를 찾아야 했다.

local_dlp_migration_log
  원본 과정 id → 신버전 마스터 id

local_dlp_migration_log 표에만 원본 id 와 마스터 id 의 대응이 있었다.

관계가 자료 구조에 없고 이관 기록에만 있는 상태였다. 원본 행에 부모를 채워 넣는 것과 로그 표를 읽는 것 두 가지 방법 중 뒤쪽을 골랐다. 이유는 원본에 부모를 채우면 차수 과정처럼 보여 다른 화면이 오독해서다.

주의 — 플래그가 아니라 권한

어떤 부서가 신버전 대상이 되는지도 함께 확인했다.

[예상]  플래그 컬럼
[실제]  특정 권한 보유 여부로 판정

Moodle 의 capability 에 붙어 있어서 local_dlp_courses 스키마를 뒤졌으면 못 찾았을 것이다.

부모 관계와 마찬가지로 직관과 다른 자리에 있었다. 자료의 실제 값에서 시작해 그 값을 쓰는 코드 분기를 따라가는 순서가 답을 냈다.

결과 — 단일 진입점과 확인 순서

구조와 별개로 다행인 것이 하나 있었다.

구 LMS API 요청
    ↓
legacy_course_route   ← 여기
    ↓
페이지들

legacy_course_route 하나라 거기만 고치면 모든 요청 종류에 적용된다.

등록과 조회와 수정이 각각 치환하는 구조였으면 세 곳을 고치고 하나를 빠뜨렸을 것이다.

이번에 확인한 순서도 함께 적어 뒀다.

① 안 되는 케이스의 실제 컬럼 값을 봄
② 그 값으로 코드에서 분기를 찾음
③ 분기가 안 타는 이유를 확인 (parent NULL)
④ 그럼 어디에 매핑이 있는지 스키마에서 찾음

코드에서 시작하지 않고 데이터에서 시작해 코드로 가는 순서였다.

기록에는 신뢰도를 갈라 적었다. 구조는 확정이지만 capability 이름과 로그 표의 정확한 이름은 쓸 때 다시 확인한다고 명시했다. 이름은 바뀔 수 있고 잘못 적으면 다음 사람이 그대로 쓰다가 틀린다.

정리

마이그레이션이 원본을 삭제하지 않고 남길 수 있다
원본은 마스터도 부모도 아니다
부모 관계로 치환하는 로직이 안 탄다
원본과 마스터의 대응이 별도 로그 표에만 있을 수 있다
대상 여부가 플래그가 아니라 권한일 수 있다
치환 진입점이 하나면 거기만 고치면 된다
실제 컬럼 값에서 시작해 코드 분기로 간다
기록에는 구조와 식별자의 신뢰도를 다르게 적는다