@g1cloud/entity-modeler-next 5.2.9 → 5.2.11

package/dist/agent/symbolicOp.d.ts

@@ -36,6 +36,12 @@ export interface AssocHandle {
  * `attribute.add`/`index.add`/`operation.add` op은 *기존* 엔티티에 자식을 추가하는 용도로 남는다.
  */
 export interface EntitySpec {
+    /**
+     * **클래스** 논리명(다국어) — `Entity.classLogicalName`. 테이블이 없는 자리(직렬화 타입
+     * `SERIALIZED_TYPE`)의 논리명이 여기 산다(그 타입은 `table` 자체를 갖지 않는다).
+     * ⚠️테이블이 있는 엔티티는 `table.logicalName`(dotted-key)이 이기므로 그쪽을 쓴다.
+     */
+    classLogicalName?: MultiLangText;
     name: string;
     /** 기본 'JPA_ENTITY'. */
     stereotype?: ClassStereotype;
@@ -112,6 +118,13 @@ export interface AttrSpec {
      * 속성 자체는 단일 식별자 `name`만 갖고, 다국어 업무명은 컬럼에 붙는다. 컬럼 생성 시에만 의미.
      */
     columnLogicalName?: MultiLangText;
+    /**
+     * **필드** 논리명(다국어) — `Attribute.fieldLogicalName`. 위 `columnLogicalName`(컬럼에 붙는 논리명)과
+     * **다른 축**이고, 컬럼이 없는 자리(직렬화 타입 `SERIALIZED_TYPE` 의 자기 필드)의 논리명이 여기 산다.
+     * 그 자리는 `dbAttrs` 가 구조적으로 0이라 컬럼 논리명을 줄 데가 없다.
+     * ⚠️컬럼이 있는 자리에서는 컬럼 논리명이 이긴다(`core/columnResolve.effectiveLogicalName`).
+     */
+    fieldLogicalName?: MultiLangText;
     /** dbAttr UNIQUE 제약. */
     unique?: boolean;
     /** dbAttr 갱신 가능 여부(JPA @Column(updatable=)). */

package/dist/core/columnResolve.d.ts

@@ -1,4 +1,4 @@
-import { Attribute, DbColumn, EmbeddableCatalog, Entity, LogicalModel, ModelId } from './types';
+import { Attribute, DbColumn, EmbeddableCatalog, Entity, LogicalModel, ModelId, MultiLangText } from './types';
 /**
  * 임베더블이 **선언하는 슬롯** 하나 — 배열 인덱스가 곧 사용처(owner) 슬롯 위치다.
  *
@@ -62,6 +62,48 @@ export interface ColumnResolveContext {
  * 대다수 정상 데이터가 도로 빈 값이 된다. 캔버스 `EntityNode.effectiveAttr`가 쓰던 시맨틱과 동일.
  */
 export declare function resolveEffectiveColumn(attr: Attribute, col: DbColumn, index: number, entity: Entity | undefined, model: LogicalModel, ctx?: ColumnResolveContext): DbColumn;
+/**
+ * MultiLangText 에 실제로 값이 있는가 — 빈 객체·전 로케일 공백은 없는 것으로 본다.
+ *
+ * ★**모듈 밖으로 열어 둔다**(종전 비공개 `hasText`) — 논리명은 객체 축이라 `||`·`??` 로는 갈리지 않고,
+ * 그 판정을 소비처가 각자 재기술하면 어긋난다. 지금 셋이 같은 것을 물어야 한다: 실효 컬럼 해소(아래),
+ * 스테레오타입 전환 시 논리명 이전(`editor/commandPlans`), 편집·표시 뷰의 폴백 판정.
+ */
+export declare function hasMultiLangText(t: MultiLangText | undefined): boolean;
+/**
+ * **실효 논리명** — 컬럼 논리명이 있으면 그것, 없으면 «필드» 논리명(`Attribute.logicalName`).
+ *
+ * ★두 저장 자리를 한 값으로 접는 **단일 출처**다. 논리명은 원래 `DbColumn` 에만 있었는데 컬럼이 없는
+ * 자리(직렬화 타입)에는 넣을 데가 없었고, 그래서 `Attribute.fieldLogicalName` 이 신설됐다(그 필드 주석 참조).
+ * 소비처가 넷이라(캔버스 행 · 탐색기 라벨·검색 · 코드젠 javadoc) 각자 `?? ` 로 재기술하면 어긋난다 —
+ * 이 리포가 `excludeDDLGeneration` 에서 정확히 그렇게 당했다.
+ *
+ * ★**컬럼이 이긴다.** 컬럼 논리명이 더 구체적인 자리이고(임베드 슬롯 상속을 이미 지난 값일 수 있다),
+ * 필드 논리명은 「컬럼이 말해 주지 않을 때」의 값이다. 그래서 직렬화 → 일반 전환 후에도 표시가 유지되고
+ * (컬럼이 없거나 논리명이 비어 필드 값이 나온다), 사용자가 컬럼 논리명을 입력하면 그쪽으로 넘어간다.
+ *
+ * ⚠️판정은 **내용 유무**다(`??` 아님) — 빈 객체 `{}` 는 편집 중간 상태로 실재하고, 그것을 「값 있음」으로
+ * 읽으면 폴백이 조용히 막힌다(`resolveEffectiveColumn` 의 임베드 상속이 같은 이유로 같은 판정을 쓴다).
+ */
+/**
+ * **실효 엔티티 논리명** — 테이블 논리명이 있으면 그것, 없으면 «클래스» 논리명(`Entity.classLogicalName`).
+ *
+ * ★`effectiveLogicalName`(속성/컬럼 축)의 **엔티티 판**이고 같은 이유로 단일 출처다 — 소비처가 다섯이다
+ * (캔버스 노드 헤더 · 탐색기 라벨·검색 · 명령 팔레트 · 코드젠 클래스 javadoc). 각자 `?? ` 로 재기술하면
+ * 어긋난다.
+ *
+ * ★**테이블이 이긴다** — 더 구체적인 자리이고, 클래스 논리명은 「테이블이 말해 주지 않을 때」의 값이다
+ * (직렬화 타입은 테이블이 아예 없다). 그래서 직렬화 → 일반 전환 후에도 표시가 유지된다.
+ *
+ * ⚠️판정은 **내용 유무**다(`??` 아님) — 빈 객체 `{}` 가 폴백을 조용히 막는 것을 피한다.
+ */
+export declare function effectiveEntityLogicalName(entity: {
+    classLogicalName?: MultiLangText;
+    table?: {
+        logicalName?: MultiLangText;
+    };
+}): MultiLangText | undefined;
+export declare function effectiveLogicalName(attr: Pick<Attribute, 'fieldLogicalName'>, col: Pick<DbColumn, 'logicalName'> | undefined): MultiLangText | undefined;
 /**
  * 실효 물리명 — override(비어있지 않은 physicalName)가 있으면 그 값, 없으면 상속 기본값.
  * 컬럼 충돌 판정(CHK-NAME-2)은 raw `''`가 아니라 이 값으로 해야 한다: 한 테이블에 같은 임베더블

package/dist/core/types.d.ts

@@ -230,6 +230,36 @@ export interface Attribute {
      * undefined/false면 불변(어노테이션 인자 생략). naturalId=false일 땐 무의미(직렬화 시 정리).
      */
     naturalIdMutable?: boolean;
+    /**
+     * 이 **필드**의 업무 논리명 — **컬럼 없는 자리 전용**(직렬화 타입 `SERIALIZED_TYPE` 의 자기 필드).
+     *
+     * ★**`DbColumn.logicalName` 과 다른 축이다.** 종전엔 논리명이 컬럼에만 있었고(`DbColumn`), 그 자리가
+     * 「필드의 표시명」 역할까지 겸했다. 컬럼 축을 지우는 전환(`columnAxisCleanupCommands`)이 들어오면서
+     * 논리명이 **딸려 나갔고**, 채울 자리도 함께 사라졌다 — 캔버스 LOGICAL 모드가 직렬화 타입의 모든 행에
+     * `(논리명)` 플레이스홀더를 띄우는데 **넣을 수단이 없는** 상태였다(2026-08-31 사용자 보고 ·
+     * 실측 13종 45필드 전량). 규율 ①(*넣는 자리 / 보이는 자리*)의 재발이고, 규율 ②의 **반대편 실수**다:
+     * 논리명은 컬럼 축에 «저장»돼 있었을 뿐 컬럼 축의 «필드»가 아니었다.
+     *
+     * ★**편집 노출은 `isColumnlessStereotype` 자리에서만** — 컬럼 있는 자리는 컬럼 논리명을 계속 쓴다.
+     * 전 속성에 열면 일반 속성에서 논리명 입력란이 **둘로 보인다**(같은 개념의 두 저장 자리). 자리마다
+     * 하나만 유효한 것이 의도다.
+     *
+     * ★**전환 시 값이 이전된다** — 컬럼 축을 비우는 자리(`columnAxisCleanupCommands` 단일 출처)가
+     * `dbAttrs[0].logicalName` 을 여기로 옮긴다(대상이 비었을 때만 = 비파괴). 반대 방향(직렬화 → 일반)은
+     * **비대칭**이다: 옮길 컬럼이 없으므로 값을 그대로 남기고, 실효 해소(`columnResolve`)가 「컬럼 논리명이
+     * 비면 이 값」 폴백으로 흡수한다(임베드 슬롯 상속과 같은 관용구). 그래서 이탈 후에도 표시가 유지되고
+     * 사용자가 컬럼 논리명을 입력하면 그쪽이 이긴다.
+     *
+     * ⚠️`description` 과 다르다 — 논리명은 **짧은 이름**(캔버스 라벨·탐색기 검색에 들어간다)이고 설명은
+     * 문장이다. 코드젠 javadoc 은 논리명 우선 · 없으면 설명으로 폴백한다(사용자 결정 2026-08-31).
+     *
+     * ★**이름에 `field` 를 박은 이유** — `DbColumn.logicalName` 과 같은 이름을 쓰면 세 자리가 깨진다:
+     * ①`attribute.update` 의 **평탄 patch 어휘**에서 충돌한다(resolver 의 `DBATTR_FLAT_KEYS` 가 평탄
+     * `logicalName` 을 이미 «컬럼 논리명» 으로 소유하고, 그 분리는 분할 검증이 지키는 불변식이다)
+     * ②그래서 어휘 키만 다르게 두면 *「patch 키 = 모델 필드명」* 원칙이 깨진다 ③코드에서 `a.logicalName`
+     * 과 `col.logicalName` 이 한 글자 차이라 오독하고 grep 이 두 축을 못 가른다.
+     */
+    fieldLogicalName?: MultiLangText;
     description?: MultiLangText;
     attributeGroup?: string;
     groupCode?: string;
@@ -342,6 +372,29 @@ export interface Entity {
     packageName?: string;
     superClass?: string;
     schema?: string;
+    /**
+     * 이 **클래스(상자)** 의 업무 논리명 — **테이블 없는 자리 전용**(직렬화 타입 `SERIALIZED_TYPE`).
+     *
+     * ★**`table.logicalName` 과 다른 축이다.** 엔티티 논리명은 원래 테이블에만 있었고(`table` 서브객체),
+     * 그 자리가 「클래스의 표시명」 역할까지 겸했다. 테이블 축을 지우는 전환(`columnAxisCleanupCommands`
+     * 의 `table = null`)이 들어오면서 논리명이 **딸려 나갔고**, 채울 자리도 함께 사라졌다 — 캔버스 논리
+     * 뷰가 직렬화 타입 **노드 이름**에 `(논리명)` 을 띄우는데 넣을 수단이 없었다.
+     *
+     * ★★**`Attribute.fieldLogicalName` 과 같은 실패의 「엔티티 판」이다.** 그 트랙(5.2.10)이 **필드 축만**
+     * 고쳤고 엔티티 축에는 같은 처방을 적용하지 않았다 — 규율 ②(*축이 사라지면 그 축의 모든 필드를 정리*)의
+     * **경계를 한 축에서만 그은** 형태다. 실측(2026-08-31)에서 v1 doc 의 `CartGift` 가 테이블 논리명
+     * **「장바구니사은품」** 을 갖고 있었고 전환으로 소실됐음이 확인돼 이 필드가 신설됐다.
+     *
+     * ★**이름에 `class` 를 박은 이유** — `logicalName` 하나로 두면 `entity.update {logicalName}`(엔티티)와
+     * `attribute.update {logicalName}`(**컬럼** 평탄 키)가 **같은 키로 다른 축**을 가리켜 AI 어휘가 모호해진다.
+     * 네 축을 이름으로 갈라 둔다: `classLogicalName` / `table.logicalName` / `fieldLogicalName` /
+     * `DbColumn.logicalName`. (엔티티 patch 화이트리스트엔 평탄 `logicalName` 이 없어 «충돌»은 없었지만,
+     * 충돌 부재가 곧 명료함은 아니다 — 사용자 결정 2026-08-31.)
+     *
+     * ★**편집 노출은 테이블 블록이 감춰지는 자리에서만** — 테이블이 있는 엔티티는 `table.logicalName` 을
+     * 계속 쓴다(입력란이 둘로 보이지 않게). 전환 시 값 이전·이탈 비대칭·실효 해소는 필드 축과 동형이다.
+     */
+    classLogicalName?: MultiLangText;
     description?: MultiLangText;
     abstractClass?: boolean;
     hasPersonalInfo?: boolean;