[Bug] boolean = true 인스턴스 필드 초기화값이 DDL DEFAULT '0'으로 반영됨

[yyubin]

boolean 필드 초기값 DDL DEFAULT 미반영 — 설계 검토 안건

현상

@Column(nullable = false)
private boolean isActive = true;

-- 기대
`active` TINYINT(1) NOT NULL DEFAULT '1'

-- 실제
`active` TINYINT(1) NOT NULL DEFAULT '0'

= false 또는 초기값 미지정 케이스는 DEFAULT '0'이 정확히 생성됨.
= true 케이스만 DEFAULT '0'으로 잘못 생성됨.

---

근본 원인

1. 타입 매퍼 하드코딩

MySqlJavaTypeMapper에서 boolean/Boolean 타입의 defaultValue가 "0"으로 정적 정의됨.

entry("java.lang.Boolean", new MysqlJavaType(..., "0")),
entry("boolean",           new MysqlJavaType(..., "0")),

2. Processor가 DEFAULT를 세팅하지 않음

ColumnBuilderFactory가 ColumnModel.defaultValue를 채우지 않으므로 항상 null.

MySqlDialect.getColumnDefinitionSql() 우선순위:

1순위: ColumnModel.defaultValue    → null (processor에서 미설정)
2순위: UUID 생성 전략
3순위: JavaTypeMapper.defaultValue → 항상 "0"  ← 여기서 결정됨

3. APT API 제약 — 핵심

VariableElement.getConstantValue()는 컴파일 타임 상수 변수(static final 필드)에서만 값을 반환함.

// static final → getConstantValue() = true (읽기 가능)
private static final boolean ENABLED = true;

// 일반 인스턴스 필드 → getConstantValue() = null (읽기 불가)
private boolean isActive = true;

JPA 엔티티에서 사용하는 인스턴스 필드의 초기화자는 바이트코드에만 존재하며, APT의 언어 모델(javax.lang.model) 레벨에서는 접근 수단이 없음.

---

영향 범위

• JPA 경유 INSERT: Hibernate가 Java 필드값을 명시적으로 바인딩하므로 런타임 무영향
• DB 직접 INSERT / seed 스크립트: DEFAULT 의존 시 false로 저장됨 → 비즈니스 로직 불일치
• 스키마 가독성: 필드 초기값이 true임에도 스키마상 DEFAULT '0'으로 표현됨

---

해결 방향 검토

방향 A — @DefaultValue Jinx 전용 어노테이션 추가

@Column(nullable = false)
@DefaultValue("1")
private boolean isActive = true;

Processor에서 @DefaultValue를 읽어 ColumnModel.defaultValue에 세팅.

장점

• APT 제약 우회 가능
• 명시적이고 의도가 명확함
• boolean 외 다른 타입(String, int 등)에도 동일하게 활용 가능

단점

• Jinx 전용 어노테이션 → JPA 표준 밖의 침습적 변경
• Java 필드 초기값과 @DefaultValue가 달라질 경우 혼란 가능
• 기존 코드에 어노테이션 추가 작업 필요 (9개 필드 → 실제 운영 코드에선 더 많을 수 있음)

---

방향 B — 타입 매퍼의 boolean "0" 제거

MySqlJavaTypeMapper에서 boolean의 defaultValue = "0" 제거.
boolean 컬럼에 DEFAULT 절 자체를 생성하지 않음.

-- 변경 전
`active` TINYINT(1) NOT NULL DEFAULT '0'

-- 변경 후
`active` TINYINT(1) NOT NULL

장점

• 코드 변경 최소
• "잘못된 DEFAULT '0'" 문제 즉시 해소
• JPA 표준 범위 내 동작 (JPA는 DDL DEFAULT를 정의하지 않음)

단점

• = false로 초기화된 필드도 DEFAULT 절이 사라짐
• DB 직접 INSERT 시 NOT NULL 컬럼에 값을 명시해야 함
  (단, 이는 현행 DEFAULT '0'보다 오히려 명확한 동작)
• 기존 마이그레이션 파일과의 diff가 발생함 (운영 중인 경우)

---

방향 C — @Column(columnDefinition) workaround 문서화 (현행 유지)

변경 없이 명시적 DDL 지정 방법을 안내.

@Column(nullable = false, columnDefinition = "TINYINT(1) NOT NULL DEFAULT 1")
private boolean isActive = true;

장점

• 코드 변경 없음
• JPA 표준 방법

단점

• 사용자가 직접 DDL 문자열을 작성해야 함 (타입명, 방언 의존)
• 근본 원인(잘못된 DEFAULT '0') 미해결 → 버그가 아니라 설계로 인정하는 것

---

방향 D — A + B 병행 (중장기)

1. 즉시: 타입 매퍼에서 boolean "0" 제거 (방향 B)
2. 추후: @DefaultValue 어노테이션 추가 (방향 A)

B로 "잘못된 DEFAULT '0'" 문제를 선제 해소한 뒤,
필요한 경우 @DefaultValue로 명시적 제어를 제공.

---

정리

질문	내용
JPA DDL에서 boolean DEFAULT는 필수인가?	JPA 스펙 미정의. 선택사항.
DEFAULT '0'이 없으면 문제가 되는가?	NOT NULL 컬럼이면 INSERT 시 값 명시 필요. JPA 경유엔 무관.
= true 필드의 실제 사용 빈도는?	도메인 검증 결과 9개. 운영 코드에서는 더 많을 가능성.
어노테이션 추가(A) vs 타입 매퍼 정리(B) 우선?	B가 더 빠르고 부작용 적음. A는 별도 기능 범위.

---

제안

단기: 방향 B 채택
타입 매퍼에서 boolean DEFAULT 하드코딩 제거.
"잘못된 DEFAULT '0'" 출력을 즉시 해소하고, 스키마를 JPA 표준에 가깝게 유지.

중장기: 방향 A를 별도 이슈로 트래킹
@DefaultValue 어노테이션은 boolean 한정이 아닌 범용 기능이므로,
별도 스펙 설계 후 독립 구현.

[yyubin]

@CodeRabbit 확인하고 어떤 방향이 제일 적절할 지 조언 ㄱㄱ

[coderabbitai]

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
gh issue view 117 --repo yyubin/jinx

Length of output: 3625

---

🏁 Script executed:

#!/bin/bash
# Find MySqlJavaTypeMapper
fd -t f "MySqlJavaTypeMapper" --exec cat {}

# Find ColumnBuilderFactory
fd -t f "ColumnBuilderFactory" --exec cat {}

Length of output: 30636

---

@yyubin 방향 D (단기 B → 중장기 A)를 추천합니다.

---

코드 분석 결과

ColumnBuilderFactory를 직접 확인했는데, .defaultValue(...) 빌더 호출이 아예 없습니다. 즉, ColumnModel.defaultValue는 항상 null이고, Dialect는 반드시 3순위인 TypeMapper의 "0"으로 fallback됩니다.

ColumnModel.defaultValue → null (ColumnBuilderFactory에서 미설정)
     ↓
TypeMapper.defaultValue  → "0" (boolean/Boolean 하드코딩) ← 항상 여기서 결정

---

방향 B (즉시 적용) — 타입 매퍼 boolean DEFAULT 제거

변경 범위가 매우 작고 리스크가 낮습니다.

MySqlJavaTypeMapper.java 수정:

- entry("java.lang.Boolean", new MysqlJavaType("java.lang.Boolean", new SqlType("TINYINT(1)", false, false), false, "0")),
+ entry("java.lang.Boolean", new MysqlJavaType("java.lang.Boolean", new SqlType("TINYINT(1)", false, false), false, null)),

- entry("boolean", new MysqlJavaType("boolean", new SqlType("TINYINT(1)", false, false), false, "0")),
+ entry("boolean", new MysqlJavaType("boolean", new SqlType("TINYINT(1)", false, false), false, null)),

MySqlJavaTypeMapperTest.java 테스트도 함께 수정:

  `@Test`
  `@DisplayName`("Boolean → TINYINT(1) ; default 0")
  void booleanMapsToTinyint() {
      JavaTypeMapper.JavaType t = mapper.map("java.lang.Boolean");
      Assertions.assertThat(t.getSqlType(0, 0, 0)).isEqualTo("TINYINT(1)");
-     Assertions.assertThat(t.getDefaultValue()).isEqualTo("0");
+     Assertions.assertThat(t.getDefaultValue()).isNull();
  }

  `@Test`
  `@DisplayName`("boolean → TINYINT(1) ; default 0")
  void primitiveBooleanMapsToTinyint() {
      JavaTypeMapper.JavaType t = mapper.map("boolean");
      Assertions.assertThat(t.getSqlType(0, 0, 0)).isEqualTo("TINYINT(1)");
-     Assertions.assertThat(t.getDefaultValue()).isEqualTo("0");
+     Assertions.assertThat(t.getDefaultValue()).isNull();
  }

결과:

-- 변경 후 (isActive = true, isActive = false, 미지정 모두 동일)
`active` TINYINT(1) NOT NULL   -- DEFAULT 절 없음, 정직한 스키마

---

방향 A (중장기, 별도 이슈) — @DefaultValue 어노테이션

B 적용 후, @DefaultValue는 별도 이슈로 설계하는 것이 좋습니다. 이유:

항목	근거
boolean 한정 문제가 아님	int, String 등 모든 타입에서 동일하게 유용한 범용 기능
ColumnBuilderFactory 수정 필요	from() / fromAttributeDescriptor() 양쪽에서 어노테이션 읽는 로직 추가
APT 제약 문서화 필요	getConstantValue() 한계를 명시한 어노테이션 설계 문서 필요

설계 스케치:

// 제안 API
`@Column`(nullable = false)
`@DefaultValue`("1")
private boolean isActive = true;
// → `active` TINYINT(1) NOT NULL DEFAULT '1'

---

방향 C는 채택하지 않는 게 맞습니다

columnDefinition 방식은 방언(dialect) 의존 문자열을 사용자가 직접 작성해야 하고, 근본 버그(= true인데 DEFAULT '0' 출력)를 그대로 두는 것이라 버그를 설계로 인정하는 셈이 됩니다.

---

요약: B로 이 PR을 닫고, A는 별도 이슈("범용 @DefaultValue 어노테이션 지원")로 트래킹하는 방향을 추천합니다. 원하시면 A 이슈 생성도 도와드릴게요!

[yyubin]

@CodeRabbit 해당 내용 바탕으로 이슈 새로 생성 ㄱㄱ

[coderabbitai]

🧩 Analysis chain

@yyubin 새 이슈를 생성했습니다! 🎉

위 스크립트 실행 결과에서 생성된 이슈 번호를 확인하실 수 있습니다. 이슈 내용 요약:

• 제목: 범용 @DefaultValue 어노테이션 지원
• 내용: #117 분석 결과를 바탕으로, boolean/int/String 등 모든 타입에서 사용 가능한 범용 @DefaultValue 어노테이션 설계 및 구현 요청
• 포함 항목: 배경, 목표, 요구사항(ColumnBuilderFactory 수정, APT 제약 명시, 우선순위 정책 등), 관련 이슈 #117 백링크
• 담당자: @yyubin

---

🏁 Script executed:

#!/bin/bash
gh issue create \
  --repo yyubin/jinx \
  --title "범용 `@DefaultValue` 어노테이션 지원" \
  --assignee yyubin \
  --body "## 개요

이슈 `#117` 에서 boolean 타입의 \`DEFAULT '0'\` 하드코딩 버그 분석 중 도출된 후속 개선 항목입니다.

## 배경

현재 \`MySqlJavaTypeMapper\`에서 \`boolean\`/\`Boolean\` 타입에 \`DEFAULT '0'\`이 하드코딩되어 있어, 사용자가 필드에 \`= true\`를 초기화해도 DDL에 \`DEFAULT '0'\`이 출력되는 문제가 있습니다.
단기 조치로 해당 하드코딩을 제거하더라도, 사용자가 컬럼에 원하는 기본값을 직접 지정할 수 있는 범용 방법이 없습니다.

## 목표

사용자가 엔티티 필드에 어노테이션을 통해 DDL DEFAULT 절을 명시적으로 지정할 수 있도록 \`@DefaultValue\` 어노테이션을 설계하고 구현합니다.

## 요구사항

- \`boolean\`, \`int\`, \`String\` 등 **모든 타입**에서 사용 가능한 범용 어노테이션으로 설계
- \`ColumnBuilderFactory\`의 \`from()\` 및 \`fromAttributeDescriptor()\` 양쪽에서 어노테이션을 읽어 \`ColumnModel.defaultValue\`에 반영
- APT(Annotation Processing Tool) 환경의 \`getConstantValue()\` 한계를 파악하고, 설계 문서 또는 주석으로 명시
- 기존 TypeMapper의 \`defaultValue\` 필드와의 우선순위 정책 명확화

## 관련 이슈

- `#117` (boolean DEFAULT 하드코딩 버그)

## 요청자

`@yyubin`"

Length of output: 41

---

🏁 Script executed:

#!/bin/bash
gh issue list --repo yyubin/jinx --state open --limit 5

Length of output: 499

---

@yyubin 이슈 생성 완료입니다! 🎉

👉 #118 - 범용 @DefaultValue 어노테이션 지원

#117 을 단기 fix(boolean DEFAULT 하드코딩 제거)로 닫고, 중장기 @DefaultValue 어노테이션 설계는 #118에서 트래킹하시면 됩니다.