데이터 변환 소개
이전 강의에서 모듈 중 하나에서는 상속을 사용하여 도메인 모델을 변경했습니다.
현재 Adrian은 기존 플레이어가 여전히 Player 엔터티에 저장된 이름과 이메일 주소를 가지고 있기 때문에 Person 엔터에 저장된 전체 이름 및 이메일 주소 데이터에 전적으로 의존할 수 없습니다. 이 데이터가 저장되는 단일 위치에서 Adrian을 지원하려면 기존 데이터를 새 구조로 변환하고 도메인 모델을 정리해야 합니다.
이러한 종류의 도메인 모델 변경은 Mendix 앱이 변화하는 비즈니스 요구 사항에 응답할 수 있고 항상 응답해야 하기 때문에 자주 발생합니다.
Adrian의 사례 옆에 있는 몇 가지 예는 다음과 같습니다.
- 주소 세부 정보를 특성으로 포함하는 Customer 엔터티를 사용하여 도메인 모델을 시작했지만 유연성과 성능을 위해 주소 정보를 참조된 엔터티로 추출하기로 결정했습니다.
- OrderNumber 특성이 정수로 설정된 Order 엔터티가 있지만 다음 릴리스부터 OrderNumber에 알파벳 문자가 포함되어야 하므로 특성 형식이 Integer에서 String으로 변경되어야 합니다.
도메인 모델 변경 유형
도메인 모델을 변경할 때는 도메인 모델의 이전 상황과 새로운 상황을 처리해야 합니다. 도메인 모델에서 속성, 엔터티 또는 연결을 삭제하거나 변경하는 순간 데이터베이스는 시작 직후와 아무 것도 변환할 수 있기 전에 그에 따라 동기화됩니다.
데이터베이스의 기존 데이터에 영향을 미치는 두 가지 유형의 변경, 즉 Type 변경과 구조적 변경을 대략적으로 구별할 수 있습니다.
Type 변경
Type 변경에는 특성 또는 연결 형식의 변경이 포함됩니다. 이러한 종류의 변경은 Mendix에서 처리합니다. 우리 모두 알고 있듯이 모든 변경이 가능한 것은 아닙니다. 사각형이 원에 맞지 않는 것처럼 문자열을 정수로 변환하는 것은 불가능합니다. Mendix 설명( 속성 유형 마이그레이션 | Mendix 문서 ) 에서 가능한 변환에 대해 자세히 알아볼 수 있습니다.
대부분의 변환은 자동으로 처리될 수 없으며 대부분의 경우 변환에 대한 더 많은 제어가 필요하기 때문에 대신 새 속성을 추가하고 Microflow를 사용하여 데이터를 변환하는 것이 좋습니다.
구조적 변경
구조적 변는 기존 구조를 대체하기 위해 새로운 엔티티, 속성 및 / 또는 연관이 도입 될 때의 변화입니다. 이러한 종류의 변환에는 이전 구조를 새 구조체로 변환하기 위한 입력이 필요합니다. 이러한 변환은 Microflow로도 수행해야 합니다.
도메인 모델 재구성
몇 가지 요구 사항은 다음과 같습니다.
- 이전 엔터티는 전환하는 동안 존재해야 한다.
- 변환은 엔터티 변경 후, 데이터베이스를 동기화한 후에 실행해야 합니다.
- 이전 엔터티는 변환 후에 더 이상 존재하지 않아야합니다
목표 달성을 위한 4단 로켓:
도메인 모델을 적절하게 확장하고 기존 데이터를 변환하는 것은 4단 로켓입니다.
- 도메인 모델 확장
- 데이터 변환 모델링
- 새 모델 배포 및 데이터 변환
- 모델 정리
그럼 각 스테이지를 소개해 드릴까요!
스테이지 1
첫 번째 단계는 이전 설정을 유지하면서 새 엔터티, 속성 및 연결로 도메인 모델을 확장하는 것입니다. 플레이어의 EmailAddress 속성의 이름을 EmailAddress_Old로 바꿨을 때와 같이 새로운 상황과 이전 상황을 나타내는 것이 무엇인지 확인합니다. 이것은 일반화로 인한 명명 충돌뿐만 아니라 적절한 속성값 식별에도 도움이 됩니다.
스테이지 2
전환 로켓의 두 번째 단계는 이전 데이터를 새로운 상황으로 변환하는 방법을 식별하는 것입니다. 여기에는 그에 따라 변환 마이크로플로우를 모델링하고 관리자가 배포 후 실행할 수 있도록 논리적 위치의 버튼에 연결하는 작업이 포함됩니다. Adrian의 경우 기존 플레이어를 모두 검색하고, 플레이어 목록을 조회한 다음, EmailAddress_Old 값을 EmailAddress 속성에, Name 값을 FullName에 복사하여 각 단일 플레이어를 변경해야 합니다.
스테이지 3
세 번째 단계는 앱을 프로덕션에 배포하는 것입니다. (물론 테스트를 한후 ...)
배포 후 관리자 계정으로 로그인하여 변환 마이크로플로우를 실행하고 모든 데이터가 제대로 변환되었는지 확인합니다. 이전 상황과 새로운 상황을 사용하는 것의 이점은 두 상황을 비교하여 보여주는 개요 페이지를 만들 수 있다는 것입니다.
스테이지 4
마지막 단계는 도메인 모델, 관련 페이지 및 마이크로플로우를 정리하고 변환 후 최종 버전을 배포하는 것입니다.
참고:
모델 정리 및 두 번째 배포를 지연하지 마십시오. 이렇게 하지 않으면 향후 릴리스에서 데이터베이스 동기화에 영향을 미치고 예기치 않은 동작이 발생할 수 있습니다.
Adrian의 앱에서는 EmailAddress_Old 및 Name 속성, 변환 마이크로 플로우 및 비교 페이지를 삭제해야 합니다.
팁:
주의 필요!: 속성을 먼저 삭제하면 이전 속성이 사용된 모든 위치에 대한 오류 목록이 표시되므로 주의가 필요합니다.
플레이어 데이터를 Person Entity에 병합
이 연습에서는 이전 Player 엔터티의 EmailAddress 및 Name 데이터가 Person의 새 속성인 FullName 및 EmailAddress에 병합되도록 Adrian에 대한 데이터 변환을 구현합니다.
1단계 - 변환 마이크로플로우 생성
변환의 첫 번째 단계는 상속 연습 중에 이미 실행했습니다. 이제 두 번째 단계부터 시작할 때입니다. 이 단계에서는 전환 로직 및 지원 페이지를 만듭니다. 이 변환을 위해서는 기존의 모든 Player를 검색하고, Player 목록을 반복한 다음, EmailAddress_Old 값을 EmailAddress 속성에 복사하고 Name 값을 FullName에 복사하여 각 단일 플레이어를 변경해야 합니다.
- 새 마이크로플로우 TEMP_Player_ConvertOldData 생성하고 이 마이크로플로우를 마스터 데이터 폴더에 저장합니다.
- 마이크로플로우를 엽니다.
- Activity를 추가합니다.
- Retrieve를 추가합니다.
- 소스를 From database 설정합니다.
- Entity를 Player로 설정합니다.
- 루프를 추가합니다.
- 입력을 PlayerList로 설정합니다.
- 루프에 Activity 을 추가합니다.
- Change object를 추가합니다.
- 개체를 $IteratorPlayer로 설정합니다.
- 새 변경 멤버 추가: FullName
- 값: $IteratorPlayer/Name
- 두 번째 변경 구성원 추가: EmailAddress
- 값: $IteratorPlayer/EmailAddressOld
- 루프 뒤에 Activity를 추가합니다.
- Activity를 Commit object(s)로 설정합니다.
- Object or List를 PlayerList로 설정합니다.
- With events: 예
- Refresh in client: 예
- 오른쪽 사이드바에서 Properties > Security > Allowed roles 로 Administrator 설정합니다.
마이크로플로우는 다음과 같아야 합니다.
2단계 - 전환 페이지 만들기
이전 단계에서는 변환 마이크로플로우를 만들었습니다. 이 단계에서는 Adrian이 이전 데이터와 새 데이터에 대한 overview와 버튼 클릭으로 변환 마이크로플로우를 트리거하는 옵션을 제공하는 페이지를 만듭니다
- 새 페이지를 만듭니다.
A. 페이지 이름: Player_Conversion_Overview
B. Navigation 레이아웃: Atlas_TopBar
C. 템플릿: Lists/List Default - 페이지를 엽니다.
A. 제목 설정: 선수 정보 마이그레이션
B. 설명 설정: Player -> Person 마이그레이션 - 추가 단추 동작을 설정합니다.
A. 캡션: 변환시작
B. 클릭 시: 마이크로플로우 호출
C. 마이크로플로우: TEMP_Player_ConvertOldData
D. Microflow settings > Edit
E. Excution > Show progress bar : Blocking
- 페이지 속성을 설정합니다.
A. Title: 선수 정보 변환
B. Visible for: Administrator - List View를 구성합니다.
A. Data source: Database
B. Entity(path): Player
C. Do you want to automatically fill the contents of the list view?: No
D. 첫 번째 열을 삭제합니다.
F. 세부 정보 단추를 삭제합니다.
G. 첫 번째 열에서 두 번째 열로 3개의 텍스트 위젯 복사
H. 첫 번째 열의 텍스트 위젯 구성:
1. Title -> Old
2. Detail Text -> Player/Name
3. 061234578 → Player/EmailAddressOld
I. 두 번째 열의 텍스트 위젯을 구성합니다:
1. Title → New
2. Detail Text → Player/FullName
3. 061234578 → Player/EmailAddress
- 새 페이지를 탐색에 연결합니다.
A. Caption: 선수정보 마이그레이션
B. Icon: refresh
C. On click: Show a page
D. Page: Player_Conversion_Overview
3단계 - 데이터 배포 및 변환
이제 변환 페이지와 마이크로플로우를 생성했으므로 변환을 실행할 차례입니다.
- 앱을 배포하고 엽니다.
- 다음을 사용하여 로그인: Adrian/Mendix123
- 새 페이지로 이동합니다.
- Player 데이터를 살펴보십시오. 이전 값은 채워져 있고 새 데이터 필드는 비어 있어야 합니다.
- 변환시작 버튼을 클릭하십시오.
- 실행 후 데이터가 새 속성으로 복사가 잘되야 합니다.
4단계 - 모델 정리 및 재배포
이제 모든 Player 데이터가 변환되었으므로 모델 정리를 시작할 수 있습니다. 이전 속성을 제거하고 이전 속성에 대한 모든 참조를 새 속성으로 변경해야 합니다.
- 도메인 모델 SoccerSquad를 엽니다.
- 엔티티 Player에서 Name 및 EmailAddress_Old 속성을 삭제합니다.
이제 18개의 오류가 있어야 합니다. - 변환을 위해 만든 페이지 Player_Conversion_Overview 삭제하고 관련 메뉴를 삭제합니다.
- 변환 마이크로플로우 TEMP_Player_ConvertOldData 삭제합니다.
이제 16 개의 오류가 있습니다. - 첫 번째 오류를 두 번 클릭하고 설정된 속성에 따라 위젯의 참조를 올바른 속성으로 변경합니다.
A. 이름 → 전체 이름
또는
B. EmailAddressOld → EmailAddress - TeamMember 접근 오류가 발생하면 SoccerSquad > Security > Entity access > Player 에 TeamMember 권한의 Read 권한 추가
- 모든 오류에 대해 이 작업을 반복합니다.
- 앱을 배포하고 엽니다.
- 다음을 사용하여 로그인: Adrian/Mendix123
- 모든 플레이어 데이터가 올바르게 표시되는지 테스트합니다.
이제 4단 로켓을 직접 발사했습니다!
