컬럼 제약 — 타입으로 나타낼 수 없는 것
값의 범위·허용 목록·필수 여부를 시트에서 읽어 변환 단계에서 검사하는 설계입니다.
시트에 적는 것
타입 뒤의 괄호 메타입니다.
int (min=1, max=99)
왜 타입으로는 안 되나
타입은 그 값이 무엇인지만 나타냅니다. int는 -1도 2000000000도 똑같이 받습니다.
「1에서 99까지」라고 정해 둔 사람은 그것을 적을 자리가 없었습니다.
적을 자리를 두고 산출물을 나중에 훑는 방식이 있었습니다. 컬럼마다 경계와 허용 목록을 적어 두고, 익스포트가 끝난 JSON을 스크립트로 돌며 검사하는 것입니다. 그 방식으로도 틀린 값은 찾아집니다 — 다만 어디를 고쳐야 하는지가 나오지 않습니다.
| 어디서 검사하나 | 무엇을 가리킬 수 있나 |
|---|---|
| 산출물 JSON을 나중에 | 「Item.json의 1,847번째 항목」 |
| 변환 단계에서 | <워크북>.xlsx : Item : AF12 |
셀을 가리키려면 셀이 아직 있을 때 검사해야 합니다. 그래서 읽는 자리로 옮겼습니다.
코어에 포함되는 것
Field.Constraints — ColumnConstraints 하나뿐입니다.
| 무엇 |
|---|
Minimum · Maximum — 숫자 범위 |
AllowedValues — 허용값 목록 |
| 각각 어느 셀에서 왔는지 |
표기는 코어에 없습니다. 이것은 레이아웃이 이미 들고 있는 것을 놓을 자리이지, 새 표기가 아닙니다. 채우지 않는 레이아웃에서는 비어 있고 검사도 일어나지 않습니다.
위치를 부분마다 따로 들고 있는 이유는 틀린 경계와 틀린 값이 다른 실수이기 때문입니다. 어느 셀이 잘못인지 메시지에 나와야 합니다.
그룹 단위 검사
「값이 없다」는 컬럼이 아니라 그룹에 대한 질문입니다.
Slot[0].Id Slot[1].Id Slot[2].Id
10 20 (없음)
이 로우의 배열은 길이 2이지 「3개 중 하나가 빈 것」이 아닙니다. 컬럼 하나씩 검사하면 짧은 로우마다 그 길이를 잘못이라고 보고하게 됩니다 — 실제로 그렇게 만들었다가 269,426건이 나왔습니다.
그래서 검사는 SerialField를 돌고, 각 로우의
ElementCountIn까지만 봅니다. 그 너머의 컬럼은 빈 값이 아니라 없는 원소입니다.
검사하지 않는 것
| 무엇 | 왜 |
|---|---|
| 기본 인덱스 | 유니크 검사가 이미 봅니다. 그리고 인덱스에 범위를 적는 것은 값의 제약이 아니라 대역 표시입니다 |
| 참조 컬럼 | 가리키는 로우가 있는지는 참조 해석이 판정합니다. 참조에 적힌 경계는 가리키는 id 대역이지 자기 값의 범위가 아닙니다 — 둘 다 보고하면 같은 실수를 두 번 세는 것입니다 |
| 값이 없는 셀 | 빈 값은 타입의 것이지 작성자의 것이 아닙니다. 경계에 대볼 것이 없습니다 |
| 숫자가 아닌 값의 범위 | 경계는 숫자에 대한 것입니다. 다른 타입에 적힌 경계는 이 검사가 판정할 수 없는 표기이고, 로우마다 그렇게 보고하면 요점이 묻힙니다 |
실제 데이터에서 나온 것
워크북 20개 · 테이블 275개 · 269,870행을 검사한 결과가 셋이었습니다.
| 무엇 |
|---|
경계가 0~1인데 값이 4 |
| 배열 가운데가 빈 원소 — 같은 원소의 다른 멤버에는 값이 있습니다 |
허용 목록 칸에 숫자 하나가 들어가 문자열 컬럼의 화이트리스트가 [1]이 되고, 45행이 걸립니다 |
셋 다 사람이 훑어서는 나오지 않을 것들입니다. 두 번째는 로드맵이 「가운데 빈칸을 거부할 것인가」로 따로 적어 둔 형태였는데, 필수값 검사가 먼저 검출했습니다.
허용 목록은 거의 쓰이지 않았습니다. 자리를 둔 테이블은 579개인데 실제로 채운 컬럼은 위의 하나뿐이고, 그것도 화이트리스트가 아니었습니다. 그래도 읽습니다 — 채워져 있으면 검사하는 것이 맞고, 채워진 그 하나가 잘못이라는 것도 알아야 하는 것이기 때문입니다.
에셋 존재 검사 — 제외했다가 되돌린 것
값이 에셋 이름이니 실제로 존재하는지 보라는 제약입니다.
처음에는 제외했습니다. 근거는 「에셋이 있는지는 게임 빌드가 아는 것이고, 시트를 읽는 쪽이 판정할 수 있는 문제가 아니다」였습니다.
그 근거의 전제가 틀렸습니다. 시트를 읽는 쪽이 판정할 수 없는 이유는 어느 폴더를 봐야 하는지 모르기 때문인데, recipe가 그것을 대면 됩니다. 이 도구가 에셋이 무엇인지 아는 것이 아니라 — 텍스처가 뭔지도, 어느 확장자가 중요한지도 여전히 모릅니다 — 「이 폴더들에 이 이름의 파일이 있는가」만 확인합니다. 그건 판정할 수 있는 문제입니다.
남은 반론은 「아직 안 만든 에셋을 미리 적어두는 경우」였고, 그것도 답이 있었습니다: 없는
파일은 경고이고, 빌드는 이미 있는 Validation.TreatWarningsAsErrors로 차단합니다. recipe
하나가 데이터 쓰는 사람과 나가는 빌드를 함께 씁니다.
지금은 asset 타입이 그 자리입니다.