객체 유형 수정과 변경 영향
객체 유형(Object type)과 속성(Property)의 변경은 이를 사용하는 앱과 워크플로에 영향을 줄 수 있습니다. 표시 정보, 데이터 연결과 식별자 변경을 구분하고 기존 편집 및 의존 앱을 검토합니다.
유형 선택과 메타데이터
홈의 Object types 목록이나 위쪽 검색으로 변경할 유형을 엽니다. Ontology Manager 탐색에서 관련 항목으로 이동할 수 있습니다.
| 설정 | 동작 및 제한 |
|---|---|
| Icon | 아이콘과 색상을 선택합니다. |
| Display names, Description | 현재 텍스트를 선택하여 단수 및 복수 이름과 설명을 바꿉니다. |
| Status | experimental, active, deprecated, example 또는 promoted를 선택합니다. promoted는 온톨로지 수준의 소유자 승인 등 상태별 조건을 따릅니다. |
| Visibility | prominent는 우선 표시, hidden은 사용자 앱의 일반 표시에서 숨김입니다. 접근 권한을 대신하지 않습니다. |
| API name | 코드에서 사용할 이름을 바꿉니다. experimental 상태에서만 변경할 수 있습니다. |
| Object type ID | 초기 생성 후에는 변경할 수 없습니다. |
객체 유형 삭제
사이드바 오른쪽 위의 점 세 개 메뉴에서 Delete를 선택하면 해당 유형과 연결된 링크 유형(Link type)을 삭제 대상으로 준비할지 확인합니다.
실제 삭제는 저장한 뒤 적용됩니다. 그 유형을 참조하는 뷰와 앱은 더 이상 정상 동작하지 않을 수 있습니다. 삭제하려면 객체 유형이 experimental 또는 deprecated 상태여야 합니다.
기반 데이터소스 추가와 제거
데이터소스 없이 만든 유형에 데이터를 추가하려면 Properties의 Edit property mapping에서 Add a backing datasource를 선택합니다. 열을 기존 속성에 매핑하고 객체 보안 구성을 검토한 뒤 저장합니다.
같은 편집기의 Datasources에서 기반 데이터소스를 제거할 수 있습니다. 이 제거는 유형이 프로젝트(Project)에 저장되어 프로젝트 권한을 사용할 때만 가능합니다. 필요한 객체 보안 정책을 구성하고 저장해야 합니다.
제거한 데이터소스와의 열 연결이 없어지는 속성은 편집 전용 속성(Edit-only property)이 되어 액션(Action)으로 값을 채웁니다. 정의를 볼 권한과 개별 객체를 볼 권한을 각각 확인합니다.
기반 데이터소스 교체
Properties의 Edit property mapping을 열고 Datasources 위쪽 Replace를 선택하여 새 데이터소스를 고릅니다.
교체하면 이전 열과 속성의 연결은 제거됩니다. 새 데이터소스의 스키마가 같을 때만 자동으로 다시 매핑합니다. 스키마가 다르면 속성을 새 열에 직접 매핑해야 합니다.
구형 Object Storage V1의 변경 영향
다음 재등록과 쓰기 반영 설명은 구형 Phonograph에 해당합니다. 현재 Object Storage V2의 사용자 편집에 쓰기 반영 데이터셋을 필수 조건으로 적용하지 않습니다.
쓰기 반영이 없는 유형
V1에서는 기반 데이터소스 교체, 기본 키(Primary key) 변경이나 유형 삭제를 저장할 때 기존 등록을 해제하고 다시 등록하거나 삭제합니다. 재인덱싱 중에는 해당 객체가 사용자 앱에서 사용할 수 없는 상태가 됩니다.
예를 들어 해당 유형을 쓰는 Workshop 앱은 재인덱싱이 끝날 때까지 영향을 받습니다. 구형 진행 상태는 Datasources의 Phonograph 패널에서 확인합니다.
쓰기 반영이 있는 유형
V1의 쓰기 반영(Writeback)은 객체의 사용자 편집을 내구성 있는 데이터셋에 저장합니다. 객체 유형과 조인 테이블(Join table)을 사용하는 다대다 링크 유형은 편집 전에 이 데이터셋이 필요했습니다.
V1은 편집 이력을 저장하고 쓰기 반영 데이터셋을 빌드할 때 이 이력을 다시 적용합니다. 기반 데이터소스 등록을 해제하면 그 편집 이력이 삭제되고 이후 쓰기 반영 데이터셋 빌드가 실패합니다.
기반 데이터소스나 기본 키 변경 외에도 한 번이라도 편집을 받은 속성의 ID 또는 기본 자료형(Base type) 같은 스키마를 바꾸면 재등록이 필요합니다. 현재 편집을 받지 않는 필드라도 과거 편집 여부를 확인합니다.
다음 변경은 재등록을 요구하지 않아 이 이유로 편집 이력을 잃지는 않습니다.
- 편집을 받은 속성의 표시 이름, 제목 키(Title key), 렌더링 힌트, 유형 클래스와 표시 여부 변경
- 한 번도 편집을 받지 않은 필드의 삭제 또는 스키마 변경
속성 편집기는 해당 필드가 편집을 받은 적이 있는지 표시합니다.
위험한 스키마 변경에서 V1은 자동으로 등록을 해제하지 않고 재인덱싱에 실패합니다. 저장한 스키마 변경을 되돌리거나, 이력 삭제 영향을 확인한 뒤 구형 Phonograph 패널에서 수동 재등록하는 절차가 필요했습니다.
오류별 조사
| 오류 이름 또는 메시지 | 원인과 처리 |
|---|---|
| Phonograph2:FoundryColumnNameNotFound | 기반 열이 없어져 속성이 미매핑 상태입니다. 다른 열에 연결하거나 필요 없는 속성을 제거합니다. |
| Phonograph2:InvalidColumnRemoval | 편집 이력이 있는 속성의 기반 열을 제거했습니다. 열을 복원합니다. 구형 V1에서 재등록을 선택할 때에는 위의 편집 이력 손실 조건을 검토합니다. |
| Phonograph2:InvalidColumnFieldSchemaChange | 편집을 받은 속성의 ID 또는 키를 바꿨습니다. 변경을 되돌리거나 구형 V1의 재등록 및 이력 영향 조건을 따릅니다. |
| OntologyMetadata:IncompatibleFoundryFieldSchemaForPropertyType | 열과 속성 자료형이 다릅니다. 예를 들어 string 열에 integer 속성이 연결된 상태입니다. 의도한 스키마를 확인하여 양쪽을 맞춥니다. |
| Phonograph2:SchemaMismatch | 기반 스키마를 바꾼 뒤 속성 자료형이 맞지 않는 경우입니다. 의도한 새 자료형으로 정의를 갱신하고 저장한 뒤 데이터셋을 빌드하고 재인덱싱합니다. |
| FieldTypeIncompatibleWithOntologyPropertyType 또는 Failed to Update Object Type in Phonograph | 데이터셋과 온톨로지가 기대하는 자료형이 일치하지 않습니다. 양쪽의 스키마 변경을 맞추고 유형 및 데이터소스 소유자와 최근 변경을 확인합니다. |
오류 이름의 Phonograph2: 접두사는 그대로 사용하여 원인을 찾습니다. 이름만 보고 현재 백엔드에서 구형 재등록 절차를 수행하지 않습니다. 변경 의도와 저장소별 처리 경로를 먼저 구분합니다.