ebson

Java 소스가 없는 모듈에서 찾은 결함Apache ShardingSphere에는 distribution/proxy-native라는 모듈이 있습니다. ShardingSphere-Proxy를 GraalVM Native Image로 빌드해 배포하기 위한 패키징 모듈로, pom.xml의 packaging이 pom이고 Java 소스가 하나도 없습니다. 모듈 안에는 pom.xml, 배포 구조를 정하는 assembly 설정, 그리고 리눅스용 Dockerfile 세 개(Dockerfile-linux-dynamic, Dockerfile-linux-mostly, Dockerfile-linux-static)가 있을 뿐입니다. 보통 기여할 거리를 찾을 때는 로직 오류나 경계 조건처럼 테스트로 재현할 수 있는 결함을 먼저 떠..

Apache ShardingSphere에 올린 Pull Request #39126 Add MySQL exception mapping for ColumnNotFoundException이 머지됐습니다. 바뀐 코드는 많지 않습니다. 열거형 상수 두 개와 if 분기 하나를 추가했고 테스트를 더했습니다. 그런데 리뷰에서 수정 요청을 한 번 받았고, 그 과정에서 오류 응답도 클라이언트와 맺은 계약이라는 점을 알게 됐습니다.방언별 예외 매퍼가 하는 일ShardingSphere-Proxy는 클라이언트 입장에서 MySQL이나 PostgreSQL 서버처럼 보여야 합니다. 그래서 프록시 내부에서 생긴 예외를 클라이언트에 돌려줄 때도 해당 데이터베이스의 오류 형식에 맞춰야 합니다. 이 변환을 맡는 곳이 database/exc..

작은 예제 파일에서 시작한 기여오픈소스에 기여해 보고 싶다는 마음은 오래 있었지만, 막상 큰 프로젝트의 저장소를 열어보면 어디서부터 손을 대야 할지 막막했습니다. Apache ShardingSphere는 JDBC 드라이버와 프록시 형태로 데이터 샤딩·암호화·읽기쓰기 분리 같은 기능을 제공하는 분산 데이터베이스 생태계인데, 코드베이스가 넓고 모듈도 많습니다. 처음부터 커널이나 파서 엔진 같은 핵심을 건드릴 자신은 없어서, 저는 상대적으로 읽기 쉬운 examples 디렉터리부터 천천히 살펴보기로 했습니다. examples/shardingsphere-parser-example는 ShardingSphere의 SQL 파서를 어떻게 쓰는지 보여주는 예제 모음입니다. 방언별로 예제 클래스가 나뉘어 있는데, 그중 Or..

예제 생성기를 살펴보다 발견한 것Apache ShardingSphere의 examples 쪽을 살펴보던 중이었습니다. ShardingSphere에는 shardingsphere-jdbc-example-generator라는 흥미로운 모듈이 있습니다. 이름 그대로, 원하는 조합(샤딩·암호화 같은 기능, 저장 모드, 트랜잭션 방식 등)을 골라 설정하면 그에 맞는 예제 프로젝트를 통째로 만들어 주는 도구입니다. 이 생성기는 FreeMarker 템플릿을 사용합니다. config.yaml에서 어떤 조합을 만들지 정하면, .ftl 확장자를 가진 템플릿들이 그 값을 받아 실제 pom.xml, YAML 설정, 자바 소스로 렌더링됩니다. 클러스터 모드의 저장소 선택지를 따라가 보니, ZooKeeper 대신 etcd를 고르면..

눈에 걸린 두 줄오픈소스에 기여할 거리를 찾을 때 저는 거창한 기능부터 뒤지지 않습니다. 오히려 사용자가 문서를 그대로 따라 했을 때 곧장 막히는 지점을 먼저 봅니다. 그런 지점은 정직하고, 검증하기 쉽고, 저처럼 그 프로젝트를 깊게 다뤄 보지 않은 사람이 확인할 수 있는 범위 안에 있기 때문입니다. 이번에 다룬 것은 Apache ShardingSphere의 Agent 배포판에 들어 있는 샘플 설정 파일 distribution/agent/src/main/resources/conf/agent.yaml이었습니다. ShardingSphere Agent는 프록시나 JDBC 위에 붙어 추적(tracing)·메트릭 같은 관찰성 데이터를 뽑아 주는 도구인데, 그 샘플에는 OpenTelemetry를 켜는 예시가 주석으..

작은 결함 하나에서 시작한 기여오픈소스에 기여한다고 하면 큰 기능을 새로 붙이는 장면을 먼저 떠올리기 쉽습니다. 그런데 제가 실제로 Apache ShardingSphere에 올려 머지된 변경은 그런 종류가 아니었습니다. 이번에 다룰 PR #39140은 MySQL binlog에서 JSON 타입 값을 읽어 들일 때 문자열을 잘못된 charset으로 디코딩하던 지점을 바로잡은, 초점이 좁은 수정입니다. 바뀐 소스 라인은 두 줄에 지나지 않습니다. 그렇지만 이 두 줄을 확신을 갖고 고치기까지는 저장소 구조를 읽고, 문제가 재현되는 조건을 이해하고, 기존 코드가 이미 지키고 있던 약속과 어긋난 부분을 확인하는 과정이 필요했습니다. 레포지토리의 모든 모듈을 한 줄씩 훑어본 것은 아닙니다. 대신 제가 다룰 수 있는 ..

작은 결함 하나에서 시작한 기여오픈소스에 무언가를 보태고 싶다는 마음은 오래전부터 있었지만, 정작 첫 걸음은 거창한 기능이 아니라 아주 좁은 범위의 버그 수정이었습니다. Apache ShardingSphere의 코드베이스를 살펴보다가, MySQL 바이너리 프로토콜에서 시간 값을 읽어 들이는 부분에 눈길이 갔습니다. 최종적으로 제가 올린 변경은 프로덕션 코드 기준으로 딱 한 줄이었습니다. 그런데 그 한 줄에 이르기까지 확인해야 했던 맥락은 생각보다 넓었습니다. 실제 변경은 아래 PR에 남아 있습니다.https://github.com/apache/shardingsphere/pull/39138ShardingSphere는 분산 데이터베이스 솔루션의 생태계로, JDBC 드라이버와 데이터베이스 프록시 형태를 모두 ..

Elasticsearch 저장소에 올린 Pull Request 한 건이 2026년 9월 15일 main에 머지됐습니다. Fix synonyms_set reload in multiplexer filter (#158115)라는 제목의 PR입니다. 제품 코드는 :modules:analysis-common 모듈의 MultiplexerTokenFilterFactory 한 파일에 13줄을 더한 것이 전부이고, 나머지는 테스트 메서드 하나와 changelog 파일입니다. Synonyms API와 재적재되는 analyzerElasticsearch에서는 동의어를 인덱스 설정에 직접 적는 대신 Synonyms API로 동의어 세트를 만들어 두고, synonym이나 synonym_graph 토큰 필터에서 synonyms_s..

Elasticsearch 저장소에 올린 Pull Request 한 건이 2026년 9월 2일 main에 머지됐습니다. Fix hard_bounds ignoring offset in histogram (#158148)이라는 제목의 PR이고, 제품 코드는 세 파일에서 한 줄씩 고친 것이 전부이고 나머지는 테스트와 changelog인 작은 수정입니다. 이 글에서는 그 한 줄이 왜 틀렸는지, 어떻게 확인했는지, 그리고 Elasticsearch의 기여 절차를 따라가면서 알게 된 점을 정리해 보려고 합니다.histogram 집계의 offset과 hard_bounds먼저 두 파라미터가 무엇인지 짚고 넘어가겠습니다. histogram 집계는 숫자 필드 값을 일정한 interval 간격의 버킷으로 나눕니다. 공식 문서에..

어디를 고칠지 정하기까지처음부터 이 버그를 노리고 들어간 것은 아니었습니다. ShardingSphere는 JDBC 드라이버와 데이터베이스 프록시를 함께 제공하는 큰 프로젝트입니다. 프록시 모드는 여러 언어의 클라이언트가 실제 데이터베이스인 것처럼 접속하도록 각 데이터베이스의 와이어 프로토콜을 직접 구현합니다. 그중 PostgreSQL 방언 쪽 코드를 읽다 보니, 확장 쿼리(extended query)에서 바인드되는 파라미터를 해석하는 디코더가 눈에 들어왔습니다. PostgreSQL의 확장 프로토콜에서는 클라이언트가 Bind 메시지로 파라미터 값을 넘길 때, 각 값을 텍스트 포맷 또는 바이너리 포맷으로 보냅니다. 배열 타입이라면 텍스트 포맷의 경우 {1,2,3}이나 {a,b,c} 같은 중괄호 리터럴로 전달..

작은 수정 하나를 고르기까지오픈소스에 기여해 보고 싶다는 생각은 오래전부터 있었지만, 막상 apache/shardingsphere 같은 큰 저장소 앞에 서면 어디서부터 손을 대야 할지 막막했습니다. 그래서 처음에는 거창한 기능을 떠올리기보다, 이미 잘 돌아가는 코드 안에서 조건 하나가 어긋난 자리를 찾아보기로 했습니다. 저장소의 모든 모듈을 한 줄씩 훑어본 것은 아닙니다. 제가 실무에서 Oracle을 다뤄 본 경험이 있어서, 데이터베이스 방언(dialect)을 처리하는 database/connector/dialect 쪽부터 눈에 익은 코드를 따라 읽어 내려갔습니다. 그러다 OracleMetaDataLoader에서 데이터베이스 버전을 확인하는 두 메서드에 시선이 멈췄습니다. Oracle은 버전에 따라 ID..

작은 로그 한 줄에서 시작한 기여오픈소스에 처음 기여할 때 가장 어려운 부분은 코드를 고치는 일이 아니라, 고칠 만한 지점을 찾는 일이라고 생각합니다. 저장소를 읽다 보면 로그 문구 하나, 조건 하나가 미묘하게 어긋난 자리를 마주치게 됩니다. 이번에 Apache ShardingSphere에 올려 머지된 제 변경도 그런 자리에서 시작했습니다. agent/core 모듈의 바이트코드 계측 어드바이저가 오류를 기록할 때, 정작 어느 클래스에서 문제가 났는지를 로그에 잘못 남기고 있던 부분을 고친 작업입니다. PR은 아래 링크에서 확인할 수 있습니다. https://github.com/apache/shardingsphere/pull/39077ShardingSphere의 Agent는 애플리케이션 코드를 직접 수정하..

통과하는 테스트가 늘 안심할 만한 것은 아닙니다오픈소스 기여를 하려고 마음먹고 저장소를 열면, 대개는 "고칠 만한 버그"를 찾으려고 합니다. 저도 처음에는 그랬습니다. 그런데 Jenkins처럼 오래 굴러온 프로젝트에서 눈에 띄는 동작 버그를 찾기란 쉽지 않았습니다. 이미 많은 사람이 오래 들여다본 코드이기 때문입니다. 방향을 조금 틀어 본 곳이 test 모듈이었습니다. Jenkins 저장소의 test 모듈에는 src/main이 없습니다. 오직 JenkinsRule 기반의 기능 테스트만 들어 있는 모듈입니다. 그래서 이 모듈에서 찾을 수 있는 결함은 "실행하면 실패하는 코드"가 아니라 다른 종류입니다. 테스트가 통과하지만, 그 통과가 실제로는 아무것도 보장하지 않는 경우입니다. 이런 결함은 CI에서 절대로..

좁은 화면에서 브레드크럼이 비어 있었습니다Jenkins 화면 위쪽에는 지금 보고 있는 위치를 알려 주는 브레드크럼 바가 있습니다. 폴더 안에 폴더가 있고 그 안에 잡이 있고 다시 빌드 번호가 붙는 구조라, 경로가 조금만 깊어져도 브레드크럼은 화면 폭을 쉽게 넘깁니다. Jenkins는 이럴 때 앞쪽 항목들을 숨기고 점 세 개짜리 오버플로 버튼을 만들어, 숨긴 항목들을 드롭다운으로 보여 줍니다. 제 화면에서는 그 드롭다운이 비어 있었습니다. 버튼은 정상적으로 나타나고 클릭하면 팝업 상자도 뜨는데, 그 안에 아무 항목도 없었습니다. 숨겨진 브레드크럼으로 돌아갈 방법이 화면 안에 남아 있지 않다는 뜻이었습니다. 브라우저 콘솔을 열어 두고 버튼을 다시 눌러 보니 TypeError: Cannot read prope..

들어가며오픈소스에 기여한다는 말은 오랫동안 저에게 한 단계 멀리 있는 일이었습니다. 큰 프로젝트의 코드는 제가 끼어들 틈이 없을 만큼 잘 정돈되어 있을 것 같았고, 설령 고칠 곳을 찾더라도 메인테이너를 설득할 만한 변경을 만들 자신이 없었습니다. 그런 막연한 거리감을 줄여 보려고 평소에 쓰던 도구의 저장소부터 천천히 들여다보기 시작했습니다. 그 도구 중 하나가 Jenkins였습니다. 이 글은 Jenkins 코어에 올린 작은 변경 한 건(#26954)이 머지되기까지의 기록입니다. 바뀐 코드는 배열에 항목 두 개를 더하고 그 위 Javadoc 한 줄을 맞춘 것이 전부입니다. 그런데 그 두 줄에 닿기까지, 그리고 그 두 줄을 머지시키기까지 배운 것이 적지 않았습니다. 변경의 크기와 배움의 크기가 비례하지 않는..

GCS 파일 상태가 0과 null을 돌려주고 있었습니다Apache Paimon은 여러 클라우드 스토리지를 Hadoop 호환 파일시스템으로 감싸 다룹니다. 각 스토리지 구현은 파일 상태를 Paimon의 FileStatus 형태로 감싸 내보내는데, 구글 클라우드 스토리지용인 paimon-gs-impl에서 이 감싸는 과정에 빈틈이 있었습니다. 이번 글에서는 그것을 메운 apache/paimon#8559를 이야기하려 합니다. 문제는 HadoopCompliantFileIO 안의 HadoopFileStatus에 있었습니다. 이 클래스는 Hadoop의 FileStatus를 감싸, 경로·크기·디렉터리 여부·수정 시각 같은 값을 감싼 대상에 위임해 돌려줍니다. 그런데 접근 시각과 소유자를 돌려주는 메서드는 오버라이드하지..

Serializable인데 serialVersionUID가 없었습니다Apache Paimon은 여러 클라우드 스토리지를 파일시스템 플러그인으로 붙입니다. 각 스토리지에는 플러그인을 로드하는 FileIOLoader 구현이 하나씩 있고, 텐센트 클라우드 COS용은 COSNLoader입니다. 이 클래스에 직렬화 식별자가 빠져 있어, 이번 글에서는 그것을 채운 apache/paimon#8555를 이야기하려 합니다. 시작은 인터페이스를 확인하는 데서였습니다. FileIOLoader는 Serializable을 상속합니다.public interface FileIOLoader extends Serializable { 즉 이 인터페이스를 구현하는 모든 로더는 직렬화 대상입니다. Paimon에서 파일시스템 로더가 직렬화되..

정상 동작이 경고로 찍히고 있었습니다Apache Paimon은 여러 클라우드 스토리지를 파일시스템 플러그인으로 지원합니다. 그중 텐센트 클라우드의 COS를 다루는 paimon-cosn-impl 모듈에서, 설정을 읽어 들이는 자리의 로그 레벨이 상황과 어긋나 있었습니다. 이번 글에서는 그것을 제자리로 돌린 apache/paimon#8554를 이야기하려 합니다. COSNFileIO는 초기화 시점에 configure에서 사용자가 준 설정 가운데 COSN 접두사를 가진 항목을 골라 Hadoop 설정으로 옮깁니다. 그 옮기는 항목마다 로그를 한 줄씩 남기고 있었는데, 그 레벨이 warn이었습니다.// AS-IShadoopOptions.set(key, value);LOG.warn( "Adding con..

오픈소스에 기여를 이어 가면서 저는 "같은 일을 하는 두 갈래 중 한쪽만 고쳐진 자리"를 자주 봅니다. 이미 누군가 문제를 인지하고 한 곳을 손봤는데, 똑같은 문제를 안고 있는 형제 코드가 그대로 남아 있는 경우입니다. 이런 자리는 대개 리뷰 부담이 작습니다. 고칠 방향을 새로 정할 필요 없이, 이미 머지된 형제의 방식을 그대로 따라가면 되기 때문입니다. 이번에 다룰 기여(#8494)도 그렇게 찾은 것입니다. OpenTelemetry Java의 OTLP exporter 테스트에서, gRPC 쪽은 이미 완화된 단언이 HTTP 쪽에는 그대로 남아 환경에 따라 깨질 수 있던 문제였습니다. 먼저 PR 링크를 남겨 둡니다. 실제 변경과 리뷰 과정은 https://github.com/open-telemetry/op..

오픈소스 기여를 이어 가면서 저는 "이미 잘 도는 코드 안에서 한쪽만 다르게 동작하는 자리"를 찾는 방식을 자주 씁니다. 새 기능을 크게 얹는 대신, 같은 일을 하는 두 갈래가 서로 어긋난 지점을 찾으면 그게 대개 버그입니다. 이번에 다룰 기여(#8493)도 그렇게 찾은 것입니다. OpenTelemetry Java의 OTLP exporter에서, 로그 레코드의 플래그 필드 하나를 두 직렬화 경로가 서로 다른 바이트로 내보내던 문제였습니다. 먼저 PR 링크를 남겨 둡니다. 실제 변경과 리뷰 과정은 https://github.com/open-telemetry/opentelemetry-java/pull/8493 에서 볼 수 있습니다. 로그 레코드에는 두 벌의 마샬러가 있습니다OpenTelemetry는 수집한 ..

오픈소스에 처음 기여를 시작할 때 가장 막막했던 건 "무엇을 고쳐야 하는가"였습니다. 큰 기능을 새로 만들 자신은 없었고, 그렇다고 오타 하나만 고치기에는 뭔가 아쉬웠습니다. 그래서 택한 방법은 이미 잘 돌아가는 코드 안에서 "한쪽만 다르게 동작하는 부분"을 찾는 것이었습니다. 이번에 다룰 기여(#8497)도 그렇게 찾은 것입니다. OpenTelemetry Java의 Prometheus exporter에서, 같은 메서드가 속성의 위치에 따라 배열 값을 서로 다른 형식으로 내보내던 문제였습니다.PR 링크를 먼저 남겨 둡니다. https://github.com/open-telemetry/opentelemetry-java/pull/8497 에서 실제 변경과 리뷰 과정을 볼 수 있습니다.Prometheus ex..

같은 모듈 안에서 비슷한 일을 하는 클래스가 여럿일 때, 어느 하나에만 개선이 들어가고 나머지는 그대로 남는 일이 있습니다. 기능이 없는 것도 아니고 버그가 눈에 띄는 것도 아니라 한동안 지나가기 쉽습니다. 이번에 LangChain4j에 올려 머지된 변경이 그런 자리였습니다. Jlama 모듈에서 모델 다운로드가 실패할 때, 채팅 모델은 인증 오류인지 모델을 못 찾은 것인지 알려 주는데 나머지 네 개는 뭉뚱그린 예외만 던지고 있었습니다.예외 타입이 뭉개지던 경로Jlama는 자바에서 모델을 로컬로 내려받아 돌리는 라이브러리이고, LangChain4j의 langchain4j-jlama 모듈이 이를 감싸 줍니다. 모델 객체를 만들 때 필요한 모델 파일을 먼저 내려받는데, 이 다운로드가 실패하면 그 실패를 어떤 ..

주소 끝의 슬래시 하나는 평소에 신경 쓸 일이 없습니다. 그런데 라이브러리가 그 주소를 다른 라이브러리에 넘겨주는 자리에서는 그 한 글자가 예외로 이어지기도 합니다. 이번에 LangChain4j에 올려 머지된 변경이 그런 경우였습니다. HuggingFace 모듈에 직접 엔드포인트 주소를 지정하면, 그 주소가 슬래시로 끝나지 않았다는 이유만으로 모델 객체를 만드는 순간 예외가 났습니다. 커스텀 주소를 넣으면 만들어지지도 않던 클라이언트당시 DefaultHuggingFaceClient는 Retrofit으로 HTTP 호출을 처리하고 있었습니다. Retrofit은 기준 주소를 받을 때 반드시 /로 끝나야 한다는 규칙을 두고, 그렇지 않으면 baseUrl must end in /라는 메시지와 함께 IllegalA..

임베딩 스토어를 쓰다 보면 메타데이터로 결과를 좁히는 일이 자주 있습니다. 문서에 붙여 둔 키-값 중에서 특정 값을 가진 것만 골라내는 흔한 작업입니다. LangChain4j는 이런 조건을 Filter라는 공통 타입으로 표현해 두고, 각 스토어 모듈이 그것을 자기 데이터베이스가 알아듣는 질의로 번역합니다. 사용하는 쪽에서는 어떤 스토어를 쓰든 같은 코드를 쓰면 되니 편한 구조입니다. 그런데 이 "번역"이라는 말 안에는 조용한 위험이 하나 들어 있습니다. 번역이 조금이라도 어긋나면, 같은 필터를 걸었는데 스토어마다 다른 결과가 나옵니다. 그것도 예외가 터지는 게 아니라 그냥 결과가 조금 달라지는 방식으로요. 이번에 LangChain4j에 올려 머지된 변경은 정확히 그 종류의 어긋남을 다룬 것이었습니다. l..

설정 문서 생성기가 &를 그냥 흘려보내고 있었습니다Apache Paimon은 설정 옵션 문서를 손으로 쓰지 않고 코드에서 생성합니다. paimon-docs 모듈의 Utils.escapeCharacters가 옵션 설명 문자열을 HTML에 안전하게 넣을 수 있도록 특수 문자를 이스케이프하는 역할을 합니다. 이 메서드가 앰퍼샌드(&)를 처리하지 않고 있어, 이번 글에서는 그것을 채운 apache/paimon#8552를 이야기하려 합니다. 기존 구현은 꺾쇠괄호만 이스케이프하고 있었습니다.// AS-ISpublic static String escapeCharacters(String value) { return value.replaceAll("", TEMPORARY_PLACEHOLDER) ..

byte[] 키를 자바 Map으로 찾으면 어긋납니다Apache Paimon의 paimon-common 모듈에는 내부 데이터 구조를 비교하고 해시하는 InternalRowUtils가 있습니다. 이 유틸리티가 MAP 타입을 비교하는 방식에 어긋난 부분이 있어, 이번 글에서는 그것을 고친 apache/paimon#8536을 이야기하려 합니다.문제는 맵의 키를 찾는 방식이었습니다. 기존 equals는 한쪽 맵의 키를 꺼내 다른 쪽 맵에서 contains와 get으로 찾았습니다. // AS-ISObject key = get(keyArray1, i, mapType.getKeyType());if (!map2.contains(key) || !equals(map1.get(key), map2.get(key),..

생성된 비교기가 부동소수점을 == 로 비교하고 있었습니다Apache Paimon은 레코드를 비교하는 코드를 실행 시점에 생성합니다. paimon-codegen 모듈의 EqualiserCodeGenerator가 필드 타입에 맞춰 RecordEqualiser의 equals 본문을 Scala 템플릿으로 찍어 내는 구조입니다. 이 생성된 비교기가 부동소수점 필드를 다루는 방식에 어긋난 부분이 있어, 이번 글에서는 그것을 맞춘 apache/paimon#8534를 이야기하려 합니다. 문제의 출발점은 원시 타입 필드를 비교하던 자리였습니다. 생성기는 정수나 부동소수점 같은 내부 원시 타입을 만나면 자바 == 연산으로 비교하는 코드를 찍어 냈습니다.// AS-IS — 내부 원시 타입은 모두 == 로 비교if (isIn..

하나만 빠진 오버라이드Apache Paimon의 타입 시스템에서 중첩 타입들은 서로 닮은 메서드 묶음을 함께 오버라이드합니다. ArrayType, MapType, VectorType, RowType은 모두 equalsIgnoreFieldId와 isPrunedFrom을 각자 구현하고 있었는데, 같은 계열인 MultisetType만 이 둘을 오버라이드하지 않고 있었습니다. 이번 글에서 이야기할 기여는 그 빠진 자리를 채운 apache/paimon#8519입니다. 이 두 메서드는 스키마를 비교할 때 쓰입니다. equalsIgnoreFieldId는 두 타입이 필드 id만 다를 뿐 구조는 같은지 판정하고, isPrunedFrom은 한 타입이 다른 타입에서 일부 필드를 덜어 낸(프루닝된) 형태인지 판정합니다. 스키..

같은 인자를 두 번 넣은 해시Apache Paimon의 paimon-api 모듈을 살펴보다가, equals와 hashCode가 서로 다른 필드를 바라보고 있는 자리를 발견했습니다. FunctionChange의 중첩 타입인 UpdateDefinition에서 hashCode()가 이렇게 되어 있었습니다.@Overridepublic int hashCode() { return Objects.hash(definition, definition);}definition을 두 번 넣고, name은 빠져 있었습니다. 이번 글에서 이야기할 기여는 이 한 줄을 바로잡은 apache/paimon#8518입니다.FunctionChange는 함수 정의의 변경을 표현하는 타입으로, 정의를 추가하는 AddDefinition, 갱..

형제 타입은 이미 고쳐져 있었습니다Apache Paimon의 타입 시스템 코드를 읽다가, 서로 닮은 형제 클래스들 사이에서 한 곳만 다르게 처리된 부분을 발견했습니다. paimon-api 모듈의 VectorType.defaultSize()는 자식 크기를 곱할 때 오버플로를 막는 헬퍼를 쓰고 있었는데, 같은 계열의 RowType·MapType·MultisetType은 그냥 정수 덧셈으로 자식 크기를 합치고 있었습니다. 이 작은 비대칭이 이번 글에서 이야기할 기여의 출발점입니다. 실제로 올려 머지된 변경은 apache/paimon#8517입니다. defaultSize()는 각 데이터 타입이 메모리에서 차지하는 기본 바이트 크기를 어림하는 메서드입니다. 예를 들어 INT는 4, BIGINT는 8을 돌려주고, ..