@g1cloud/entity-modeler-next 5.1.4 → 5.1.5

package/dist/core/scaffoldJava.d.ts

@@ -1,4 +1,4 @@
-import { Entity, LogicalModel, ModelId, SuperClassCatalog, EmbeddableCatalog } from './types';
+import { Association, Attribute, Entity, LogicalModel, ModelId, SuperClassCatalog, EmbeddableCatalog } from './types';
 import { JavaTypeDef } from './javaTypes';
 /**
  * `AttributeConverter` FQN 기본값 — **레거시 생성기 상수 미러**(`bluework-im` `EntityJavaFile.java:77~78`
@@ -128,4 +128,38 @@ export interface ScaffoldedEntity {
  */
 export declare function isGeneratable(entity: Entity): boolean;
 export declare function scaffoldEntityJava(logical: LogicalModel, targetIds: readonly ModelId[], opts?: ScaffoldOptions): ScaffoldedEntity[];
+/**
+ * 식별 FK가 `@MapsId`(관용구4)인지 판정 — **단일 컬럼 @OneToOne 식별 FK**는 대상 PK를 공유하는 파생
+ * 식별이다(실물 OrderShipping: `@Id String orderNo` + `@MapsId @OneToOne order`가 order_no 컬럼 공유).
+ * 이 경우 FK는 스칼라 @Id에 매핑될 뿐 별도 PK 멤버가 아니므로 PK 카디널리티 카운트에서 제외한다.
+ * 걸러지는 쪽 = 직접 @Id 멤버(관용구3 @Id@ManyToOne[단수 아님]·관용구5 대상 복합키[컬럼 2+]).
+ *
+ * ★★**종전엔 조건이 하나 더 있었다** — *"스칼라 @Id와 같은 물리 컬럼을 공유"*. 그 조건은 모델에 스칼라
+ * PK가 **실재할 것**을 요구했는데 FK 전파는 FK 속성만 만들고 스칼라를 만들지 않으므로(`propagation.ts`)
+ * **프로덕션 발동이 0**이었고, 실물이 `@MapsId` 21/21인데 모델은 22건 전부 관용구5로 방출되는 **전면
+ * 드리프트**가 났다. 스칼라 필드는 이제 **방출 시점에 합성**하므로(`derivedIdFieldName` ?? 부모 PK
+ * 물리명 camelCase — 실물 관행 19/19) 그 조건이 불요해졌고, 모델은 **속성 하나**를 유지한다
+ * (⇒ 물리명 중복이 생기지 않아 `CHK-NAME-2`·DDL 이 무변경). 근거=`.claude/docs/MapsIdIdiom-entry_2026-08-26.md` §3.A.
+ * ★관용구5(`@Id`를 연관 필드에 직접)는 JPA 정식이지만 **이 코드베이스 실물에 0건**이라 선택지를 두지
+ * 않았다(§3.A (가) 확정 — 요구가 관측되면 관용구 선택 축을 신설).
+ */
+export declare function isMapsIdFk(fk: Attribute, assoc: Association | undefined): boolean;
+/**
+ * `@MapsId` FK가 매핑되는 **스칼라 @Id의 필드명**. 모델 지정(`derivedIdFieldName`)이 우선이고, 없으면
+ * **부모 PK 물리명의 camelCase**로 파생한다(실물 21건 대조 19/19 — 모델 속성명 폴백은 18/19로 이름 결손
+ * 1건에서 어긋나므로 물리명 쪽을 택했다). 부모 컬럼도 미해소면 FK 자신의 물리명, 그마저 없으면 빈 문자열
+ * (호출부가 fillIn으로 표면화).
+ */
+export declare function mapsIdScalarName(fk: Attribute, assoc: Association, byId: Map<ModelId, Entity>): string;
+/**
+ * `@MapsId` 스칼라 @Id의 **Java 타입** — 이름과 **같은 경로**(`derivedFrom.sourceAttributeRef`)로 조달한다.
+ *
+ * ★`pkMemberFieldType(fk, …)`을 직접 쓰면 안 된다 — 그 함수는 부모를 **`member.type`(엔티티명)으로 조회**
+ * 하는데 **실 데이터의 FK 속성은 `type`이 빈 문자열**이다(전파가 채우지 않는다 — 실측 `PaymentMethodPolicy`
+ * `{name:'paymentMethod', type:''}`). 그러면 부모 미해소로 `Object`가 나간다(실물은 `String`). 반면
+ * `derivedFrom`은 부모 PK 속성을 **modelId로 직접** 가리키므로 해소율이 19/19다.
+ * ⚠️이것은 이 변경이 만든 결함이 아니라 **선재 결함의 노출**이다 — 같은 경로를 `{Entity}PK` 필드 타입과
+ * 단일키 Repository 타입도 쓰고 있어 그쪽도 `Object`가 나가고 있었다.
+ */
+export declare function mapsIdScalarType(fk: Attribute, assoc: Association, byId: Map<ModelId, Entity>, logical: LogicalModel, opts: ScaffoldOptions): string;
 export {};

package/dist/core/types.d.ts

@@ -224,6 +224,20 @@ export interface Attribute {
         /** 부모의 어느 식별자 속성을 미러하는가 */
         sourceAttributeRef: ModelId;
     };
+    /**
+     * 파생 식별 관용구(`@MapsId`)에서 방출되는 **스칼라 식별자 필드명**.
+     *
+     * 이 속성의 `name`은 **연관 필드명**(`@MapsId @OneToOne` 필드 · `mappedBy` 소스)이고, 같은 관계가
+     * 만드는 **두 번째 Java 필드**가 스칼라 `@Id`다 — 종전엔 `name` 하나가 두 역할을 겸해 이 이름을 담을
+     * 자리가 없었다(엔티티 행과 엣지 인스펙터가 **같은 `name`을 편집**한다: `PropertyPanel.navFieldName`
+     * ↔ `EntityAttributesWide`). 컬럼은 공유하므로 **속성은 여전히 하나**이고, 물리명·타입은 파생이다
+     * (`dbAttrs[0].physicalName` 또는 부모 컬럼명 / 부모 PK의 Java 타입).
+     *
+     * 미지정 시 **부모 PK 물리명의 camelCase**로 폴백한다 — 실물 관행 19/19이므로 발명이 아니다
+     * (모델 속성명 폴백은 18/19: 이름 결손 1건에서 어긋난다). `isMapsIdFk` 미발동 형상(관용구3
+     * `@Id@ManyToOne`·관용구5 대상 복합키·비식별 FK)에서는 무시된다.
+     */
+    derivedIdFieldName?: string;
     /**
      * 임베더블 인라인 EMBED hydration의 출처(load-only, 화면 표시 전용).
      * 레거시는 임베더블 타입의 플래튼 컬럼 묶음을 소유자 association end에 인라인(EMBED_OWN)으로만