데이터 모델 업데이트

주요 변경 사항

기존 클라이언트(새 코드 및 스키마로 업데이트되지 않은 클라이언트)는 여전히 이전 스키마 정의를 통해 데이터에 액세스해야 하기 때문에 호환성이 손상되는 스키마 변경은 어렵습니다. 업데이트된 클라이언트는 새로운 스키마 변경 사항을 적용해야 합니다.

호환성이 손상되는 변경과 호환성이 손상되지 않는 변경 빠른 참조

단절적 변경은 서버 측 스키마에서 처리하기 위해 추가 조치가 필요한 변경을 말합니다. 서버 측의 단절적 스키마 변경을 하려면 백엔드에서 동기화를 종료한 다음 동기화를 다시 허용해야 합니다. 단절적 스키마 변경으로 인해 클라이언트가 Realm을 열 수 없거나 서버 측 문서가 클라이언트 측 애플리케이션과 동기화되지 않아 데이터 손실이 발생할 수 있습니다. 단절적 스키마 변경은 클라이언트 재설정 시 애플리케이션이 자동으로 복구되는 것을 방지합니다.

주요 변경 사항은 앱에서 추가 처리 없이 서버 측 스키마 또는 객체 모델에서 수행할 수 있는 변경입니다. 추가 변경이라고도 하는 이 기능은 동기화 영역에 자동으로 적용됩니다.

참고

클라이언트에 호환성이 손상되지 않는 변경을 적용하려면 마이그레이션이 필요할 수 있습니다

서버 사이드 스키마에 호환성이 손상되지 않는 변경만 적용하는 경우에는 추가 조치가 필요하지 않습니다. 그러나 클라이언트 객체 모델에 이러한 변경 사항을 적용하려고 하면 마이그레이션을 수행해야 할 수도 있습니다. 클라이언트 장치에 기존 Realm 파일이 있는 경우 마이그레이션을 수행해야 합니다. 자세한 내용은 원하는 SDK의 객체 스키마 수정 페이지를 참조하세요.

다음 다이어그램은 수행할 수 있는 스키마 변경 유형과 변경을 수행하기 위해 거쳐야 하는 프로세스를 보여줍니다. 이러한 각 변경 사항은 아래 표와 섹션에 자세히 설명되어 있습니다.

이 테이블에는 각 변경 유형과 해당 변경이 단절적인지 비단절적인지 요약되어 있습니다.

변경 유형	서버 측 스키마	클라이언트 측 객체 모델
객체 유형 추가	호환성이 손상되지 않음	호환성이 손상되지 않음
속성에 기본값 추가하기	호환성이 손상되지 않음	호환성이 손상되지 않음
필수 속성 추가하기	호환성이 손상되지 않음	호환성이 손상되지 않음
선택 속성 추가하기	호환성이 손상되지 않음	호환성이 손상되지 않음
객체 유형 제거	손상	호환성이 손상되지 않음
선택적 또는 필수 속성 제거	손상	호환성이 손상되지 않음
객체 유형 이름 변경	호환성이 손상됨*	호환성이 손상됨*
속성 이름 변경	호환성이 손상됨*	호환성이 손상됨*
속성 유형은 변경하되 이름은 그대로 유지	손상	손상
속성의 상태를 선택 사항이나 필수 사항으로 변경	손상	손상

팁

속성 이름 바꾸기

속성이나 객체의 이름을 바꾸는 것은 주요 변경 사항이지만 일부 Realm SDK는 속성 이름을 다시 매핑하는 해결 방법을 제공합니다. 자세한 내용 은 속성 이름 변경 을 참조하세요.

객체 유형 추가

추가 처리를 수행하지 않고도 서버 사이드 스키마 또는 클라이언트 객체 모델에 객체 유형을 추가할 수 있습니다.

서버 측 스키마와 클라이언트 객체 모델 모두에 객체 유형을 추가하려면 객체 모델에 객체 유형을 추가하고 개발 모드를 사용하여 App Services가 서버 측 스키마 업데이트를 추론하도록 할 수 있습니다. 또는 모델과 스키마 모두에 객체 유형을 수동으로 추가할 수 있습니다.

속성에 기본값 추가하기

객체의 필수 속성에 기본값을 추가할 수 있습니다. 필수 속성이 없는 Atlas 문서를 컬렉션에 삽입하면 Realm 클라이언트가 속성을 기본값으로 설정합니다. 그러나 클라이언트가 속성을 변경하거나 Atlas에서 직접 문서를 업데이트할 때까지 Atlas 문서에 있는 동일한 속성은 비어 있는 상태로 유지됩니다.

기존 Atlas 문서를 수정할 때 기본값이 어떻게 유용한지에 대한 자세한 내용 은 필수 속성 추가를 참조하세요.

필수 속성 추가하기

클라이언트의 객체 모델에 필수 속성을 추가하고 개발 모드를 사용하여 App Services에서 서버 사이드 스키마 업데이트를 유추하도록 할 수 있습니다. 또는 클라이언트 모델과 Atlas 스키마 모두에 필수 속성을 수동으로 추가할 수 있습니다. 하지만 기존 Atlas 문서를 수정할 필요가 없도록 속성을 선택 사항으로 설정하는 것을 고려해야 합니다.

선택적 속성 추가하기

서버 측 스키마와 클라이언트 객체 모델 모두에 선택적 속성을 추가하려면 객체 모델에 선택적 속성을 추가하고 개발 모드를 사용하여 App Services가 서버 측 스키마 업데이트를 추론하도록 할 수 있습니다. 또는 모델과 스키마 모두에 선택적 속성을 수동으로 추가할 수 있습니다.

객체 유형 제거

클라이언트의 객체 모델에서 객체를 호환성이 손상되지 않는 변경으로 제거할 수 있습니다. 서버 사이드 스키마에서 객체를 제거하면 이는 호환성이 손상되는 변경입니다. 이러한 이유로 클라이언트 사이드 객체 모델에서만 객체 유형을 제거하고 서버 사이드 스키마에는 그대로 두는 것이 좋습니다.

속성 제거하기

클라이언트측 객체 모델에서 선택적 또는 필수 속성을 제거하고 서버측 스키마에 그대로 둘 수 있습니다. 이는 객체 모델에 영향을 주지 않는 변경입니다.

서버 사이드 스키마에서 속성을 제거하면 이는 호환성이 손상되는 변경입니다. 이러한 이유로 클라이언트 사이드 객체 모델에서만 속성을 제거하고 서버 사이드 스키마에는 그대로 두는 것이 좋습니다.

이전 버전과의 호환성을 유지하기 위해 클라이언트 쪽 객체 모델에서 속성을 제거해도 데이터베이스에서는 속성이 삭제되지 않습니다. 대신 새 객체는 제거된 속성을 유지하며, App Services는 해당 값을 적절한 빈 값(예: nullable 속성의 경우 null, 정수 값의 경우 0, 문자열 값의 경우 빈 문자열)으로 설정합니다.

객체 이름 변경하기

서버 측 스키마와 클라이언트 측 객체 모델 모두에서 객체 이름을 변경하는 것은 주요 변경 사항입니다. 그러나 일부 SDK는 새 객체 이름을 스키마의 기존 이름에 매핑하는 API를 제공합니다. 이렇게 하면 클라이언트에 있는 객체 이름을 바꿀 수 있지만 서버의 객체 이름은 변경할 수 없습니다. 이런 방식으로 마이그레이션이 트리거되는 것을 방지할 수 있습니다. 객체 이름 매핑은 다음 SDK에서 지원됩니다.

• Kotlin

• Java

• .NET

• Flutter

이름 매핑이 옵션이 아닌 경우, 기존 컬렉션과 스키마를 유지하고 새 스키마로 새 컬렉션을 만드는 파트너 컬렉션 전략을 구현하는 것이 좋습니다.

파트너 컬렉션 전략을 사용하는 대신 객체 이름을 변경하기로 선택한 경우 동기화를 종료하고 스키마를 수동으로 업데이트한 후 동기화를 다시 허용해야 합니다. 또한 동기화를 복원하려면 클라이언트 애플리케이션에서 클라이언트 재설정을 수행해야 합니다. 기본 클라이언트 재설정 모드에서 클라이언트는 재설정하기 전에 동기화되지 않은 변경 사항을 복구하려고 시도합니다.

속성 이름 변경

서버 쪽 스키마와 클라이언트 쪽 객체 모델 모두에서 속성 이름을 변경하는 것은 호환성이 손상되는 변경입니다. 그러나 일부 SDK는 새 속성 이름을 스키마의 기존 이름에 매핑하는 API를 제공합니다. 이를 통해 클라이언트의 속성 이름을 바꿀 수 있지만, 서버의 속성 이름은 변경할 수 없습니다. 이런 방식으로 마이그레이션이 트리거되는 것을 방지할 수 있습니다. 속성 이름 매핑은 다음 SDK에서 지원됩니다.

• Flutter: 속성 다시 매핑하기

• Java: 필드 이름 바꾸기

• Kotlin: 속성 다시 매핑하기

• .NET: 속성 이름 바꾸기

• Node.js: 속성 다시 매핑하기

• React Native: 속성 재매핑

• Swift: 속성 다시 매핑하기

이름 매핑이 옵션이 아닌 경우, 기존 컬렉션과 스키마를 유지하고 새 스키마로 새 컬렉션을 만드는 파트너 컬렉션 전략을 구현하는 것이 좋습니다.

파트너 컬렉션 전략을 사용하는 대신 속성 이름을 변경하기로 선택한 경우 동기화를 종료하고 스키마를 수동으로 업데이트한 다음 동기화를 다시 허용해야 합니다. 또한 동기화를 복원하려면 클라이언트 애플리케이션에서 클라이언트 재설정을 수행해야 합니다. 기본 클라이언트 재설정 모드에서 클라이언트는 재설정하기 전에 동기화되지 않은 변경 사항을 복구하려고 시도합니다.

동기화를 종료했다가 다시 허용하는 경우, 기존 Atlas 문서도 업데이트하여 클라이언트 애플리케이션과 동기화할 수 있도록 해야 합니다. 이 추가 처리가 없으면 해당 문서가 동기화되지 않으며 클라이언트에서 데이터가 손실된 것처럼 보일 수 있습니다. 이 문제는 두 가지 방법으로 해결할 수 있습니다.

• 새 스키마와 일치하도록 각 문서의 이전 필드 이름을 변경합니다.

• 새 스키마와 일치하는 이름으로 각 문서에 새 필드를 추가하고 이전 필드의 값을 복사합니다.

이렇게 변경한 후에는 해당 문서가 클라이언트 애플리케이션에 동기화됩니다.

속성 유형은 변경하되 이름은 그대로 유지

속성 유형을 변경하는 것은 서버측 스키마와 클라이언트측 객체 모델 모두에 큰 변화를 가져옵니다.

속성의 유형을 변경하는 대신 기존 collection과 스키마를 유지하고 새 스키마로 새 collection을 만드는 파트너 collection 전략을 구현하는 것이 좋습니다.

파트너 컬렉션 전략을 사용하는 대신 속성 유형을 변경하기로 선택한 경우 동기화를 종료하고 스키마를 수동으로 업데이트한 다음 동기화를 다시 허용해야 합니다. 또한 동기화를 복원하려면 클라이언트 애플리케이션에서 클라이언트 재설정을 수행해야 합니다. 기본 클라이언트 재설정 모드에서 클라이언트는 재설정하기 전에 동기화되지 않은 변경 사항을 복구하려고 시도합니다.

동기화를 종료했다가 다시 허용하는 경우, 기존 Atlas 문서도 업데이트하여 클라이언트 애플리케이션과 동기화할 수 있도록 해야 합니다. 이 추가 처리가 없으면 해당 문서가 동기화되지 않으며 클라이언트에서 데이터가 손실된 것처럼 보일 수 있습니다. 이 문제는 두 가지 방법으로 해결할 수 있습니다.

• 새 스키마와 일치하도록 각 문서의 이전 필드 유형을 변경합니다

• 새 스키마와 일치하는 유형을 사용하여 각 문서에 새 필드를 추가하고 이전 필드의 값을 복사하여 해당 유형을 변환합니다.

이러한 변경을 수행한 후에는 해당 문서를 클라이언트 애플리케이션에 다시 한 번 동기화해야 합니다.

속성의 상태를 선택 사항과 필수 사이에서 변경합니다.

속성 상태를 선택 사항 또는 필수 사항으로 변경하는 것은 서버 사이드 스키마와 클라이언트 사이드 객체 모델 모두에 대해 호환성이 손상되는 변경입니다.

속성의 상태를 변경하는 대신 기존 collection과 스키마를 유지하고 새 스키마로 새 collection을 만드는 파트너 collection 전략을 구현하는 것이 좋습니다.

파트너 컬렉션 전략을 사용하는 대신 속성 상태를 변경하기로 선택한 경우 동기화를 종료하고 스키마를 수동으로 업데이트한 후 동기화를 다시 활성화해야 합니다. 또한 클라이언트 애플리케이션에서 클라이언트 재설정을 수행하여 동기화를 복원해야 합니다. 기본 클라이언트 재설정 모드에서 클라이언트는 재설정하기 전에 동기화되지 않은 변경 사항을 복구하려고 시도합니다.

파트너 컬렉션 전략 사용

파트너 collection은 원본 컬렉션과 동일한 데이터를 포함하지만 새로운 스키마 정의가 포함된 컬렉션입니다. 파트너 collection은 데이터베이스 트리거를 사용하여 데이터가 양방향으로 흐르도록 합니다. 즉, 한 컬렉션에 작성될 때 다른 컬렉션에도 작성됩니다(새 스키마에 필요한 데이터 수정 포함).

파트너 컬렉션 전략을 사용하여 획기적인 스키마 변경을 구현하려면 획기적인 스키마 변경하기를 참조하십시오.