Baserow - 행 업데이트 작업 #1645

모니카쿠스터 게시일: 2024년 10월 22일

사용자가 Baserow 데이터베이스 테이블 내의 특정 행을 수정할 수 있도록 Baserow 구성 요소에 대한 행 업데이트 작업을 구현합니다.

작업 속성:

• 테이블 ID - 행을 업데이트하려는 테이블의 ID
• row id - 업데이트하려는 행의 ID
• user_field_names - 이 엔드포인트에서 반환된 필드 이름이 필드의 실제 이름이어야 하는지 여부를 나타내는 부울
• fields - 필드 맵과 테이블의 새 값입니다. 이 속성은 행에서 업데이트할 데이터를 지정하여 사용자가 단일 작업으로 여러 필드를 변경할 수 있도록 합니다.

출력:

• row - 지정된 테이블의 행과 연관된 모든 데이터 필드 및 값을 포함하는 업데이트된 행 객체

문서 참조: https://baserow.io/api-docs

</div>
<div class="gh-btn-container"><a class="gh-btn" href="https://github.com/bytechefhq/bytechef/issues/1645">View on GitHub</a></div>

로그인 후 복사

이 문제에 참여하기 전에는 Java를 최소한으로 사용했습니다. 나는 학교 과정의 일부로 작은 JavaFX 프로그램을 수행한 적이 있었지만 더 많은 것을 배우고 싶었습니다. 나는 시간을 내서 조금씩 배워왔기 때문에 패키지, 액세스 수정자, 종속성, 프로젝트에서 사용하는 빌드 도구인 Gradle과 같은 개념에 어느 정도 익숙했습니다. 이러한 사실을 알면 이 프로젝트에 참여하는 것이 훨씬 덜 위협적입니다. Gradle 프로젝트가 각각 다른 빌드 구성을 가진 하위 프로젝트와 하위 패키지로 구성되는 방식을 배웠기 때문에 프로젝트 구조를 이해했습니다.

반 친구인 Arina는 우리 둘 다 같은 프로젝트를 진행하고 있다는 사실을 알아차렸고 친절하게도 구성 요소 추가에 대한 개발자 문서와 해당 구성 요소에 대해 이미 정의된 작업에 대한 링크를 제공하여 나에게 몇 가지 조언을 해주었습니다. 이는 관련 파일/디렉토리를 찾기 위해 저장소를 직접 살펴볼 필요가 없다는 것을 의미했습니다. 하지만 꼭 해야 한다면 git grep, GitHub의 코드 검색 또는 IntelliJ의 검색을 사용했을 것입니다. 제가 작업할 컴포넌트의 히스토리를 확인하기 위해 git Blame을 사용했는데, 한 번의 커밋으로 모두 개발된 것을 확인했습니다.

프로젝트에 기여한 문서는 단계별 지침이 자세히 설명되어 있어 따라하기가 매우 쉬웠습니다. 하지만 프로젝트가 매우 초기 단계인 것처럼 보였습니다. // TODO라고만 표시된 몇 가지 README 파일을 발견했습니다.

변경하기 전에 어떻게 작동하는지 확인하기 위해 프로그램을 컴파일하고 실행해 보았지만 힘든 과정이었습니다. 제가 작성한 메모는 다음과 같습니다.

컴파일을 마친 후(1시간 이상 소요) 기존 컴포넌트를 확인하기 위해 실행해봤습니다. 클라이언트를 사용하기 위해 계정을 만들려고 했는데 안 되어서 기여 문서로 돌아가서 개발에 사용할 수 있는 관리자 계정이 함께 제공되는 것을 발견했습니다. 이 계정은 docker를 실행할 때 생성되는 것 같습니다. -작곡.

일단 로그인해서 Baserow 컴포넌트를 만들어 보았는데, 클라이언트가 좀 느려서 실수로 복제해버렸습니다. 삭제하려고 하면 클라이언트가 정지되어 새로 고침을 눌렀고 서버 오류가 발생하기 시작했으며 클라이언트 시간이 초과되었습니다. 서버와 클라이언트를 다시 시작해 보았으나 시간이 오래 걸렸습니다. 다시 한 시간 정도 걸릴 것 같았습니다. 약 16분 정도 기다린 후 밤에 통화하고 나중에 작업하기로 결정했습니다.

4일 후

이 프로젝트로 돌아가서 한 시간 동안 긴 컴파일 시간을 처리해야 한다는 것이 두려웠지만 Hacktoberfest가 거의 끝나가면서 선택의 여지가 별로 없었습니다. 그러니 프로젝트가 오류 없이 구축되어 5분도 안 되어 실행되었을 때 제가 얼마나 놀랐는지 상상해 보십시오. 무엇이 바뀌었나요? 모르겠어요.

그래서 클라이언트에 접속해서 Baserow 컴포넌트를 찾았습니다.

그림 - Baserow 구성 요소 및 해당 구성 요소에 대한 기존 작업

Create Row 액션을 추가하려면 관리자가 링크해 준 Baserow API 문서를 살펴봐야 했습니다. 문서를 보기 위해 Baserow 계정을 만들어야 했는데 좀 이상하다고 생각했는데 그것도 큰 문제는 아니었습니다.

그래서 기존 작업인 '행 만들기'를 테스트했는데 페이지 전체가 오류 메시지로 바뀌는 버그가 발생했습니다. 예상치 못한 값을 입력한 줄 알았는데 나중에 이 버그가 나와 관련 없는 별도의 문제에 의해 이미 추적되고 있다는 것을 알게 되었습니다.

다음 테스트 시도에서 Create Row 액션이 성공했기 때문에 액션이 어떻게 생성되는지 이해하기 위해 연구하는 것이 좋은 후보라고 판단했습니다. 문제, 기존 작업, 기여 문서를 상호 참조하면서 따라갔습니다.

액션은 필요한 입력 매개변수, 출력 스키마, 액션이 수행하는 실제 프로세스를 정의하는 메서드를 정의하여 생성된다는 것을 배웠습니다.

행 만들기 작업에서 입력 매개변수를 정의하는 데 사용되는 테이블 행의 필드를 가져오는 방법이 있다는 것을 확인했습니다. 내 작업에서 이것을 사용할 수 있다는 것을 깨달았지만 행 만들기 작업에만 사용하도록 의도된 것처럼 이름이 지정되었습니다. 사용하는 것이 타당하다고 생각하여 그대로 사용하고 관리자에게 알리기로 결정했습니다.

Baserow API 문서를 읽을 때 행을 업데이트하려면 "PATCH"라는 HTTP 메서드를 사용한다는 사실을 알게 되었는데, 이 메서드가 있는지도 몰랐습니다. PATCH는 PUT과 비슷하지만 리소스를 교체하는 대신 부분적으로 변경합니다. 흥미로운 내용입니다.

그래서 실제로 액션을 작성하게 되었고, 기존 액션에서 전체 코드를 거의 끌어올릴 수 있었습니다. 허용된 매개변수(업데이트할 행을 식별하기 위해 행 ID를 추가함), 출력 스키마 및 호출된 메소드(엔드포인트 및 HTTP 메소드 변경)를 약간만 조정하면 되었습니다. 행 ID를 허용하려면 Baserow 구성 요소와 관련된 모든 상수가 포함된 Constant/ 하위 디렉터리의 파일에 상수를 추가해야 했습니다.

기존 소스 코드 파일에는 모두 라이선스 헤더가 있다는 것을 알고 이를 내 파일에도 복사했습니다. 가져오기를 정리하고 코드 형식을 지정하고 수동으로 테스트할 차례였습니다.

이 시점에서 Create Row 작업(이미 존재하는 작업)에 대한 설명이 잘못되었음을 알았습니다. 단순히 생성할 수 있다고 말하는 대신 이름으로 참조되는 Baserow의 샘플 데이터베이스에 행을 생성한다고 나와 있습니다. 행. 저는 관리자에게도 이 내용을 언급하기 위해 메모를 남겼습니다.

그림 - Create Row 구성요소에 대한 잘못된 설명

내 작업이 클라이언트에 나타났고 시각적으로 모든 것이 좋아 보였습니다.

제목과 설명이 표시되었습니다:

표시된 속성(예: 입력 매개변수):

워크플로가 성공적으로 실행되었으며 성공적인 응답을 받았습니다.

그리고 내 Baserow 계정에서 표가 업데이트되었습니다.

변경 사항에 만족하여 포맷터와 테스트를 실행했지만 테스트 중 하나에서 Baserow 구성 요소에 하나의 작업만 수행할 것으로 예상했기 때문에 테스트에 실패했습니다. 새로운 작업을 수용하도록 테스트를 업데이트하고 구성 요소에 대한 문서를 자동으로 생성하는 스크립트를 실행했습니다. 테스트를 다시 실행하면 통과했지만 여전히 내 작업에 대한 단위 테스트를 추가해야 했습니다. 기존 컴포넌트에 대한 단위 테스트를 보다가 머리를 긁적였습니다. 나는 상당한 진전을 이루었다고 판단하여 하루를 마치고 PR 초안을 열고 내가 발견한 문제를 관리자에게 알렸습니다.

이튿날

기존 테스트가 무섭게 보였지만 액션에도 하나 추가할 수 밖에 없었기 때문에 돌아가서 기존 테스트에서 무슨 일이 벌어지고 있는지 이해하려고 노력했습니다. 나는 사용된 테스트 라이브러리인 JUnit Jupiter와 Mockito를 조금 살펴보았습니다. 나는 그것을 조금씩 분석하려고 시도했고 LLM을 사용하여 각 줄에서 무슨 일이 일어나고 있는지 이해하는 데 도움을 주었습니다. 하지만 솔직히 말해서 나는 아직도 무슨 일이 일어나고 있는지 막연하게만 이해하고 있었습니다. 나는 Baserow API를 조롱하고 거기에서 내 작업의 메서드를 호출하고 있다는 것을 알고 있었지만 그것이 내가 이해한 정도였습니다.

그래도 충분히 좋았던 것 같습니다. 내 PR을 검토할 준비가 되었다고 표시했고 관리자가 내 변경 사항을 수락했습니다! 그들은 몇 가지 피드백을 제공했습니다. 비록 읽었음에도 불구하고 기여 흐름의 일부 부분을 따르는 것을 잊어버렸습니다. 다음번에는 끌어오기 요청을 작성하기 전에 기여 문서를 검토해야 합니다.

Baserow 구성 요소에 대한 업데이트 행 작업 생성 #1656

우데이-라나 게시일: 2024년 10월 29일

설명

수정 #1645

변경 유형

• 새로운 기능(기능을 추가하는 획기적인 변경 사항)
• 이 변경에는 문서 업데이트가 필요합니다

이것은 어떻게 테스트되었나요?

• 새로운 작업을 수용하도록 업데이트된 BaserowComponentHandler 정의 테스트로 테스트되었습니다.
• 클라이언트를 통해 수동으로 테스트된 작업:

체크리스트:

• [x] 내 코드는 이 프로젝트의 스타일 지침을 따릅니다
• [x] 내 코드에 대한 자체 검토를 수행했습니다
• [ ] 코드, 특히 이해하기 어려운 부분에 주석을 달았습니다.
  • 기존 작업에는 댓글도 포함되지 않으므로 댓글이 필요하다고 간주되지 않습니다
• [x] 문서에 해당 변경 사항을 적용했습니다
• [x] 변경사항이 새로운 경고를 생성하지 않습니다
• [x] 수정 사항이 효과적이거나 기능이 작동하는지 확인하는 테스트를 추가했습니다
• [x] 변경 사항에 따라 신규 및 기존 단위 테스트가 로컬에서 통과됩니다.

GitHub에서 보기

저는 초기 설정과 테스트 작성이 이 문제에서 가장 어려운 부분이라고 생각했습니다. 실제로 이 기능을 추가하는 것은 비교적 쉬운 일이었습니다. 하지만 이 문제에서 제가 정말 멋있다고 생각한 점은 잘 관리된 문서와 이해하기 쉬운 코드 덕분에 제가 잘 모르는 언어로 프로젝트에 기여할 수 있었다는 것입니다.

그리고 그것이 Hacktoberfest 2024의 마지막 PR이었습니다! 요약 포스팅은 곧 올라옵니다!