63 lines
6.0 KiB
Markdown
63 lines
6.0 KiB
Markdown
---
|
|
title: interview-prep / native-query-addscalar-runtime-validation
|
|
source_type: interview-prep
|
|
status: raw
|
|
related_branches: [experiment-nplus1-feed-api-replay]
|
|
related_projects: [ca-skeleton]
|
|
tags: [interview-prep, ca-skeleton, persistence, testing, hibernate, postgresql, static-analysis]
|
|
created: 2026-07-15
|
|
status_label: drafting
|
|
---
|
|
|
|
# interview-prep: native-query-addscalar-runtime-validation
|
|
|
|
> Layer: `raw/interviews/` — 면접 질문 원본 수집·연구 노트입니다. 다듬어진 답변은 canonical 문서를 만든 뒤 `wiki/interview/`에 별도로 작성합니다.
|
|
|
|
## Parent / 부모
|
|
|
|
- [[raw/branch-notes/experiment-nplus1-feed-api-replay]] — D5가 `addScalar`의 runtime 결과 mapping과 SQL compile-time 검증을 구분하고, D4가 실제 PostgreSQL 검증 경계를 소유합니다.
|
|
|
|
## 질문 / Question
|
|
|
|
- 질문 원문: Hibernate native query에서 `addScalar`를 썼는데도 SQL 문법이나 table/column 이름 오류를 Java compile-time에 잡을 수 없는 이유는 무엇이며, 어떤 검증으로 보완하셨습니까?
|
|
- 출처: N+1 replay의 L12 native child projection을 설명할 때 예상한 면접 질문입니다.
|
|
- 받은 날짜·맥락: 실제 면접에서 받은 질문은 아닙니다.
|
|
|
|
## 질문 의도 추론 / Why this question
|
|
|
|
- 핵심 평가 대상: Java 타입 검증, ORM 결과 mapping, database SQL 실행 검증의 경계를 구분하는지 평가합니다.
|
|
- 함정 / 흔히 빠지는 답변 패턴: `addScalar`가 SQL parser나 schema checker라고 설명하거나, Java compilation만으로 native SQL의 table/column 오류까지 검증됐다고 말하는 답변입니다.
|
|
- 따라올 만한 후속 질문: 결과 컬럼의 runtime type이 맞지 않으면 어디서 실패하나요? Testcontainers만으로 query plan이나 production latency까지 말할 수 있나요?
|
|
|
|
## 답변 재료 / Raw answer material
|
|
|
|
- 사실 1: 이 작업에서 `addScalar`는 native-query result extraction의 runtime type mapping으로 다뤘습니다. SQL 문자열의 문법, table/column 이름, query plan을 Java compiler가 검증하는 기능은 아닙니다. (근거: [[raw/branch-notes/experiment-nplus1-feed-api-replay]] D5, §3 Crown과 L12의 의도적 차이)
|
|
- 사실 2: `addScalar` type이 실제 결과와 맞지 않거나 native SQL이 잘못되면 Java compile이 아니라 integration/runtime 실행에서 실패합니다. (근거: [[raw/branch-notes/experiment-nplus1-feed-api-replay]] §엣지·실패·의존)
|
|
- 사실 3: 보완 수단으로 `FeedReadModelUseCaseIT`를 포함한 focused Gradle integration suite와 fresh Docker Compose PostgreSQL HTTP/SQL-row-count smoke를 수행했습니다. 이는 실제 PostgreSQL에서 query를 실행하는 검증입니다. (근거: [[raw/branch-notes/experiment-nplus1-feed-api-replay]] D4, §검증 기록)
|
|
- 프로젝트 작업에서 확인한 경험: L12 native child mapping을 `addScalar`로 실행했고, final L12 Docker smoke에서 reset, Crown feed, read-model response, invalid page HTTP 400, marker row count를 local 환경에서 확인한 기록이 있습니다. (근거: [[raw/branch-notes/experiment-nplus1-feed-api-replay]] §Docker HTTP + PostgreSQL smoke — final L12 tag)
|
|
- 트레이드오프: 이 작업의 선택은 Java compiler가 확인할 수 있는 코드 오류와 실제 PostgreSQL 실행이 확인할 native SQL 오류를 분리하는 방식입니다. `addScalar`만으로 검증 범위를 넓힌다는 선택은 채택하지 않았습니다. 업계 다수파·소수파에 대한 일반화는 이 raw note의 근거 범위 밖입니다. (근거: [[raw/branch-notes/experiment-nplus1-feed-api-replay]] D5)
|
|
- 한계 / "이건 안 해봤다": 실행한 test case와 fixture가 덮지 않은 SQL branch, representative production data에서의 query plan, latency SLA는 이 검증만으로 판단하지 않았습니다. (근거: [[raw/branch-notes/experiment-nplus1-feed-api-replay]] §Out of scope, §검증해야 할 주장)
|
|
|
|
## Sources / 근거 (답변의 사실 근거)
|
|
|
|
- [[raw/branch-notes/experiment-nplus1-feed-api-replay]] D5 — `addScalar`를 Java SQL compile-time checker로 설명하지 않는 결정과 runtime mapping 경계.
|
|
- [[raw/branch-notes/experiment-nplus1-feed-api-replay]] D4 — Testcontainers에 더해 fresh Docker Compose PostgreSQL에서 HTTP response와 SQL row count를 확인하는 검증 선택.
|
|
|
|
## 미해결 / Unknown
|
|
|
|
- PostgreSQL version, migration 순서, 실제 데이터량이 달라질 때 모든 native SQL path가 계속 유효한지는 별도 검증이 필요합니다.
|
|
- `addScalar` mapping 변경이 API response contract에 미치는 영향은 fixture 기반 integration test만으로 모두 포괄했다고 말할 수 없습니다.
|
|
- 확인 방법: relevant migration을 적용한 PostgreSQL에서 각 native-query endpoint와 `FeedReadModelUseCaseIT`를 실행하고, representative data에서는 `EXPLAIN (ANALYZE, BUFFERS)`와 별도 load test를 수행합니다.
|
|
|
|
## 답변 경계 / Answer boundary
|
|
|
|
- 자신 있게 말할 수 있는 범위: 이 repository의 L12 native query에 대해 `addScalar`가 runtime 결과 mapping이고, 실제 PostgreSQL integration/runtime 실행으로 오류를 발견하도록 검증했다는 local evidence 범위입니다.
|
|
- "이 부분은 공식 문서를 다시 보고 답변드리겠습니다" 라고 해야 하는 부분: Hibernate version별 API 세부사항, 다른 database vendor의 type coercion, 모든 SQL path의 coverage와 production query plan입니다.
|
|
- **절대 과장하지 말 것**: `addScalar`가 SQL syntax/schema를 compile-time에 검증한다고 말하지 않습니다. Testcontainers 결과를 모든 production data와 latency의 검증으로 말하지 않습니다. 한 번의 integration test가 native SQL의 모든 오류를 찾는다고 말하지 않습니다.
|
|
|
|
## Related / 관련
|
|
|
|
- 관련 작업: [[raw/branch-notes/experiment-nplus1-feed-api-replay]]
|
|
- 관련 면접 질문: [[raw/interviews/crown-one-query-vs-cqrs-lite-read-model]]
|
|
- 답변 derive 후 위치: canonical 문서가 준비된 뒤 `wiki/interview/persistence/native-query-addscalar-runtime-validation.md`
|