Object Storage v2 이전 시 기능 차이

Object Storage v1(Phonograph)의 저수준 API에 직접 의존하는 앱은 Object Storage v2로 이전하기 전에 호출과 데이터 모델을 검토해야 합니다. OSv2는 Funnel을 통한 인덱싱과 용도별 객체 데이터베이스를 사용하므로, Phonograph가 제공하던 기능을 같은 API로 그대로 제공하지 않습니다.

편집 경로와 데이터셋

OSv2의 사용자 편집은 액션(Action)을 통해 적용합니다. Phonograph 편집 API를 직접 호출하는 코드는 이전 전에 액션 호출로 바꿔야 합니다.

OSv1에서 편집을 위해 필요했던 쓰기용 데이터셋(Writeback dataset)은 OSv2에서 구체화 데이터셋(Materialized dataset)에 대응합니다. OSv2의 구체화는 선택 사항이며, 사용자 편집을 켜기 위한 필수 데이터셋이 아닙니다. 온톨로지 상태를 후속 파이프라인에서 사용해야 할 때 구성합니다.

기존 편집과 편집 이력

이전 과정에서 객체의 편집 이력을 보존할지 선택할 수 있습니다. 보존하면 이력을 처리하고 저장하는 추가 컴퓨팅과 저장 비용이 발생합니다.

보존을 선택하지 않아도 기존 편집을 반영한 객체의 최신 상태는 이전합니다. 다만 OSv1의 전체 편집 이력은 OSv2에서 사용할 수 없으며, 이전이 끝난 뒤 복구할 수 없습니다. 액션 로그는 별도의 기록으로 유지되므로, 편집 이력의 보존과 액션 로그를 구분해야 합니다.

OSv2에서 이후의 편집 이력을 추적하려면 Ontology Manager의 Track user edit history를 켜고 객체 뷰에 Edit History 위젯을 추가합니다. 결정 단위의 기록이 필요하면 액션 로그와 Workshop의 Action Log Timeline을 구성할 수 있습니다.

데이터 검증과 증분 반영

OSv2는 기본 키와 속성 자료형의 데이터 제약을 적용하며, Geopoint 속성도 더 엄격하게 검증합니다. 이전 대상의 기본 키와 속성이 인덱싱 검증을 통과하는지 확인해야 합니다.

변경 로그(Changelog) 데이터소스에서는 레거시 데이터셋의 latest timestamp wins 규칙을 사용하지 않습니다. OSv2의 파이프라인은 기본으로 증분 인덱싱을 수행하고 Funnel이 필요한 변경 계산을 처리하므로, 구형 changelog Python 데코레이터에 의존하는 방식을 그대로 적용하지 않습니다.

모니터링과 조회 API

OSv2 객체 유형은 모니터링 뷰로 감시합니다. Phonograph의 동기화 상태 상태검사(Sync status health check)를 그대로 사용하는 방식은 대체해야 합니다.

OSS API는 Phonograph의 query string 기능을 지원하지 않습니다. 여기서 query string은 Phonograph의 해당 검색 구문이며, HTTP URL에 일반적인 질의 매개변수를 붙일 수 있는지에 관한 설명이 아닙니다.

OSv1과 OSv2 객체가 함께 있는 다중 백엔드 객체 집합에는 OSS cardinality 지표를 사용할 수 없습니다.

기능 격차를 확인할 구성

다음 구성은 OSv2에서 지원하지 않거나 제한됩니다.

• 상류 대상과 하류 대상 사이의 일정 연결 경로가 구체화를 통과하는 구성
• 사용자 지정 분석기(Custom analyzer)
• Foundry Rules Archetypes에서 다중 데이터소스 객체 유형 또는 구체화를 여러 개 가진 객체 유형을 입력으로 사용하는 구성

이 차이로 이전이 차단되거나 기존 앱이 이전 후 실패할 수 있습니다. 이전 절차의 비호환 사용 분석에서 차단 오류와 시작은 허용되지만 이후 실패할 호출을 각각 확인합니다.