@g1cloud/entity-modeler-next 5.0.9 → 5.0.10

package/dist/core/javaTypes.d.ts

@@ -22,6 +22,29 @@ export declare function javaTypeLabel(value: string): string;
  * 호출자가 타입을 비워 "모른다"를 보존한다. 위 `JAVA_TYPE_BY_DATA_TYPE` 주석의 결정 근거 참조.
  */
 export declare function javaTypeFromDataType(dataType: string | undefined): string | undefined;
+/**
+ * 자바 타입 ↔ 물리 DB 타입 호환 판정. `CHK-TYPE-7`의 판정 산식(단일 출처).
+ *
+ * 반환값 3-상태: `true` 호환 · `false` 부정합 · **`undefined` 판정 불가**(호출자는 skip한다). undefined는
+ * ①어느 한쪽이 빈값 ②자바 타입이 `DATA_TYPES_BY_JAVA_TYPE` 밖(임베더블·주입 customtype·CustomType)
+ * ③물리 타입이 `ALL_DATA_TYPES` 밖(미지 값 — 그 축은 `CHK-TYPE-1`이 타깃 다이얼렉트 기준으로 지목한다.
+ * 여기서 함께 신고하면 한 컬럼에 두 경고가 겹치고 사용자가 할 일이 갈린다).
+ *
+ * ★★**정수형 × `NUMERIC`/`DECIMAL`은 정밀도 무관 호환**이다(2026-08-24 운영 DB 실측으로 확정).
+ * 이 자리에 한때 *"무정밀도면 부정합"* 조건이 있었고 **실측이 그것을 무너뜨렸다** — 근거 이력을 남긴다:
+ *  · 1차 근거는 실물 **Java 필드 타입**이었다(`private int`이므로 컬럼도 정수여야 한다).
+ *  · 그런데 리포의 **Flyway 프로덕션 마이그레이션**(`src/main/resources/db/migration/V*.sql` · 컬럼 9,254)
+ *    을 대조하니 운영 DB 가 실제로 `NUMERIC`이었다 — 정밀도있음 395 중 **293이 DDL 에 있고 280이 정밀도
+ *    값까지 일치**(291 numeric : 2 integral), 무정밀도 축도 **85건이 DDL 에서 무정밀도 `NUMERIC`** 이다
+ *    (`series.depth NUMERIC NOT NULL` · `sort_order NUMERIC DEFAULT 999`). `ALTER COLUMN … TYPE` 전량에
+ *    **numeric → integer 전환이 0건**이라 이 판정은 stale 하지 않다.
+ *  · ⇒ `int` 필드 × `numeric` 컬럼은 **이 프로젝트의 운영 형상**이다. `Boolean × VARCHAR`(Y/N 컨버터
+ *    766건)와 **같은 구조**이고, 도구가 결함이라 부르면 오탐이 된다.
+ * ★판정 근거는 *Java 타입이 무엇을 읽는가*가 아니라 **컬럼이 실제로 무엇인가**다 — 이 프로젝트의 스키마는
+ * Hibernate 가 아니라 마이그레이션이 만들고(`dbTypes.ts` 주석), Hibernate 는 정수 필드의 `precision`을
+ * 무시하므로 어노테이션은 *의도*일 뿐이다.
+ */
+export declare function isJavaDataTypeCompatible(javaType: string | undefined, dataType: string | undefined): boolean | undefined;
 /**
  * ① 스칼라 자바 타입 셀렉트 후보(단일 출처). JAVA_TYPES에서 비후보(⑤·레거시 표시용)를 빼고
  * ④ CustomType은 "사용자정의" 안내 라벨로 노출. ②embeddable·③customtype은 애초에 JAVA_TYPES에 없음.