자동 모드 마이그레이션

이 시리즈의 첫 번째 섹션에서는 "Evolutionary Database Design, GraphQL, APIs, and Database Schema Migrations: Part 1"을 사용할 수 있습니다.
두 가지 주요 경로를 따를 수 있다. 하나는 내가 본 블로그 글에서 상세하게 소개할 자동 수동 방식이고, 다른 하나는 Hasura 컨트롤러 인터페이스를 사용하는 도형 방식이다. 이것은 후속 글에서 소개할 것이다.우선 두 방법 모두 Hasura CLI 도구에서 시작합니다.보기documentation,저는 댓글Hasura CLI Installation & Notes을 썼습니다. 더 많은 정보를 알고 싶습니다.이 전제 조건이 충족되면 우리는 데이터 모델 모델과 우리가 구축하고자 하는 내용을 구축할 수 있다.

왜?

본 시리즈의 첫 번째 문장Evolutionary Database Design, GraphQL, APIs, and Database Schema Migrations: Part 1에서 논의한 바와 같이 우리는 왜 모델 이전을 둘러싸고 좋은 실천을 하기를 원하는지 개술하였다.설정과 사용의 실제 예시를 이해하기 위해 저는 다음과 같은 데이터베이스 모델을 만들었습니다.

이 모델에는 많은 시계와 이 시계 간의 관계가 있다.일대다, 다대다, 심지어 일부 귀속 관계.

초기 마이그레이션

우선, 우리는 기본표를 만들고 관계를 추가해야 한다.적어도 이것이 가장 간단한 방법이 될 것이다.첫 번째 모드 마이그레이션의 경우 이러한 테이블을 작성하는 데 필요한 SQL을 함께 배치합니다.테이블을 만든 후에 관계와 다른 요소를 추가할 것입니다.이것은 우리의 첫 번째 이동을 구성할 것이다.

CREATE TABLE "Source" (
  "Id" uuid PRIMARY KEY,
  "Stamp" timestamp,
  "Name" text,
  "Uri" text,
  "Details" text
);

CREATE TABLE "SourceNotes" (
  "SourceId" uuid,
  "NotesId" uuid,
  "Details" text,
  "Stamp" timestamp
);

CREATE TABLE "NoteJot" (
  "Id" uuid PRIMARY KEY,
  "Stamp" timestamp,
  "NoteId" uuid,
  "Details" text
);

CREATE TABLE "Activity" (
  "Id" uuid PRIMARY KEY,
  "Stamp" timestamp,
  "Activity" json
);

CREATE TABLE "Connection" (
  "Id" uuid PRIMARY KEY,
  "Stamp" timestamp,
  "ActivityId" uuid,
  "SourceId" uuid
);

CREATE TABLE "Formatter" (
  "Id" uuid PRIMARY KEY,
  "Stamp" timestamp,
  "ConnectionId" uuid,
  "FormatterMap" json
);

CREATE TABLE "Schema" (
  "Id" uuid PRIMARY KEY,
  "Stamp" timestamp,
  "ConnectionId" uuid,
  "SchemaMap" json
);

여기서 주의해야 할 중요한 세부 사항 중 하나는 이 초기 이전이 우리가 하고 싶지 않은 일들을 깨뜨렸다는 것이다.다음은 첫 번째 이전의 몇 가지 문제입니다.

마이그레이션에는 여러 가지 측면이 있습니다.일반적으로, 목표는 매번 이전할 때마다 하나의 단일한 절차를 유지하는 것이다. 예를 들어 테이블 만들기, 열 추가, 관련 추가 등이다.

처음 이전한 후에 새 테이블을 만들 때, 우리는 이 특정 단계에서 모든 테이블의 창설이나 열을 추가하면 각자의 관계를 추가할 수 있도록 이전을 만들기를 희망합니다.

다음 단계에서 우리는 표의 정렬에 주의할 필요가 없다. 관계가 있는 표는 어떤 관계를 그리기 전에 모든 표를 존재하게 하고 표를 만드는 특정한 상반된 순서에 따라 표를 삭제하거나 다른 삭제를 해야 하기 때문이다.

그러나 이것은 초기 모델 이전이기 때문에 초기 테이블 모델을 신속하게 추가한 다음에 이러한 핵심 테이블이 존재한 후에 더 많은 교체 변경을 하기 시작한다.

개시하다

마이그레이션을 생성하기 전에 구성 파일을 초기화하고 해당 Hasura API와 데이터베이스를 가리켜야 합니다.이 예에서, 나는 초기화 명령만 실행하고, 스위치를 사용하지 않으며, 기본 옵션을 받아들인다.hasura init
첫 번째 모드 마이그레이션을 생성하려면 Hasura CLI 명령을 사용합니다.새로 만든hasura 디렉터리로 이동하여 다음 동작을 수행합니다.hasura migrate create "inception"결과가 반환되어 마이그레이션의 이름과 버전이 표시됩니다.

이 폴더를 열려면 Visual Studio 코드나 원하는 편집기를 사용하는 것이 좋습니다.다음 그림에서는 폴더를 Visual Studio 코드로 열고 열었습니다.우리가 방금 만든 이동된 ql 파일입니다.

이 때, 파일은down처럼 비어 있습니다.ql 파일.이게 뭐야?sql와down.ql 파일?우리 토론 좀 합시다.

마이그레이션 회의 위아래 변동

매번 이전할 때마다 데이터베이스 모델을 최신 버전으로 업데이트하는 경로가 있고, 데이터베이스 모델을 이전 버전으로 복구하는 경로가 있습니다.매번 이전할 때마다 이 두 개의 교체 절차가 필요하다.하수라 CLI 사용법을 보면 두 개의 명령이 반복적으로 왔다 갔다 이동하는 것과 관련이 있다.
계속해서, 또는 우리가 만들 이전을 실행하려면, 다음 명령을 실행할 것입니다.hasura migrate apply이것은 모든 업데이트된 이전을 실행하고 데이터베이스 모델을 최신 버전으로 업데이트합니다.만약 우리가 이 변경 사항을 다시 돌려서 이전 모드의 이전 버전으로 이동해야 한다면, 다음 명령은 다음 버전의 이전을 실행할 것입니다.hasura migrate apply --down 1

위로 이동

좋습니다. 첫 번째 마이그레이션을 완료하기 위해 SQL에서 수행해야 할 단계와 SQL에서 수행해야 할 단계입니다.위의 SQL을 up으로 복사합니다.ql 파일.

우리는 현재 hasura migrate apply 명령을 실행할 수 있지만,down을 위해drop 명령을 구축할 수 있습니다.ql 우선.이렇게 하면, 만약 어떤 오류가 발생한다면, 우리는 즉시 굴러갈 수 있을 것이다.비록 이것은 첫 번째 단계에서 결코 중요하지 않지만, 이전을 실행하기 전에 시종일관 상하 두 단계를 구축하는 것은 좋은 실천이다.
이 때 이 테이블들은 관계를 사용하지 않기 때문에drop 명령은 임의의 순서가 될 수 있습니다.만약 우리가 관계를 그렸다면, 이 관계들은drop 명령으로 테이블을 열거하고, 관계를 삭제하는 순서에 따라 삭제해야 합니다.일반적으로 실행 모드를 이동할 때 우리는 이 문제를 겪지 않을 것이다. 왜냐하면 이동 자체는 충분한 작은 작업 단원이기 때문에 우리는 복잡한 문제를 겪지 않을 것이다.특정 시점에 관계식이나 테이블만 만듭니다.

아래로 이동

테이블마다 삭제하는drop 명령은 다음과 같습니다.DROP TABLE "Source"; DROP TABLE "SourceNotes"; DROP TABLE "NoteJot" ; DROP TABLE "Activity"; DROP TABLE "Connection"; DROP TABLE "Formatter"; DROP TABLE "Schema";하나하나 다 밑에 넣으세요.ql 파일.

지시 및 실행

다음 단계에서는 Hasura 인스턴스에 대한 마이그레이션을 수행합니다.자신의 실례를 얻고 직접 시도하기 위해quick 5 minute and 37 second video 무료 층 하수라 실례를 설정하는 것에 대한 조언이 있습니다.나는 지금 네가 이미 자신의 예를 가지고 있다고 생각한다.마이그레이션을 즉시 수행하려면 인스턴스의 URI가 필요합니다.그림과 같이 인스턴스의 콘솔을 찾아 URI를 가져옵니다.

이제 프로파일을 엽니다.프로젝트 폴더 구조 루트 디렉토리에 있는 yaml 파일과 localhost URI를 변경하고 새 URI 경로를 추가합니다.이제 URI에서 경로/v1/graphql를 삭제하면 기본 URI만 구성에 포함됩니다.yaml 파일.이렇게 보여요.

파일을 저장하고 Hasura CLI를 사용하여 마이그레이션을 수행합니다.hasura migrate apply컨트롤러로 이동해서 데이터 옵션을 누르면 다음 표를 볼 수 있습니다.

지금, 만약 우리가 다시 굴러가고 싶다면, 아래의 명령을 보내 주십시오.hasura migrate apply --down 1 한 단계 뒤로 이동합니다.완료되면 데이터 탭을 다시 볼 때 브라우저에서 새로 고침을 클릭하여 업데이트되었는지 확인하고 테이블을 삭제합니다.

이러한 변경 사항을 계속 적용하면, 우리는 이것을 본 시리즈의 다음 부분의 기초로 삼을 것이다.3부에서는 콘솔 자체를 사용하여 마이그레이션을 구축하는 방법에 대해 설명합니다.우리는 테이블과 다른 모델 변경 사이에 관계를 추가할 것이다. 이전 과정에서 무엇을 했는지, 무엇을 하지 않았는지, 그리고 메타데이터가 하수라 이전과 어떻게 일치하는지, 완전한 교체 버전 제어를 제공하고 데이터베이스 변경과 하수라 API 서버 자체의 변경 사이를 왔다 갔다 이동하는지 토론할 것이다.

요약

이러한 단계를 완료한 후 첫 번째 마이그레이션이 완료되었습니다.여기에 소개된 절차를 돌이켜보면 처음에는 간단해 보일지라도 우리에게 넓은 시야를 제공할 수 있다.처음에 나는 실현해야 할 모델을 제공했다.다음은 이 모드에서 각 테이블을 작성하는 데 필요한 SQL입니다.마지막으로 저는 hasura init를 사용하여 schemamigrations 프로젝트 폴더 구조를 만드는 과정과 첫 번째 이전 폴더의 창설을 소개했습니다.sql와down.ql 파일.그때부터 우리는 위아래로 이동하는 절차에 필요한 SQL을 추가하고 설정을 다시 그리기 위해 함께 일했다.yaml-URI는 각자의 Hasura API 서버에 도착하여 우리의 첫 번째 상향 이동을 실행했습니다.그리고 우리는 아래로 이동하는 것을 끝냈다. 단지 앞뒤를 비교하기 위해서였다. 그리고 위로 이동하는 것을 끝냈다. 우리는 다음 문장을 위해 준비를 하자!