@g1cloud/entity-modeler-next 5.2.28 → 5.2.29

package/dist/core/javaTypes.d.ts

@@ -1,4 +1,4 @@
-import { Entity, Association, Attribute, DbColumn, DisplayMode, EmbeddableCatalog, PredefinedCustomTypeCatalog, PredefinedCustomTypeEntry } from './types';
+import { Entity, Association, Attribute, DbColumn, DisplayMode, EmbeddableCatalog, EmbeddableCatalogEntry, PredefinedCustomTypeCatalog, PredefinedCustomTypeEntry } from './types';
 export interface JavaTypeDef {
     /** 저장값 = 레거시 enum 상수명. Attribute.type에 그대로 들어간다. */
     value: string;
@@ -157,12 +157,48 @@ export declare function typeOwner(attr: Pick<Attribute, 'attrType'>): TypeOwner;
  *
  * ★소비처가 둘이고 **하는 일이 다르다**: GUI 는 `structural` 을 «자리 보존 전환»(`convertAttributeType`
  *   — 삭제+추가 합성)으로 **처리**하고 나머지는 셀렉트를 잠그며, AI(`agent/resolver`)는 patch 로 표현할
- *   수 없으므로 **전부 거부**한다(op 배치는 `attribute.remove`+`attribute.add`(+`reorder`)로 같은 일을
- *   낼 수 있어 표현력 부족이 아니다). 판정선만 공유하고 처방은 각자다 — 선이 갈리면 *「GUI 로는 되는데
- *   AI 로는 조용히 반쪽 적용」* 이 된다.
+ *   수 없으므로 거부한다. 판정선만 공유하고 처방은 각자다 — 선이 갈리면 *「GUI 로는 되는데 AI 로는
+ *   조용히 반쪽 적용」* 이 된다.
+ * ⚠️★**AI 쪽 「전부 거부」는 2026-09-04 에 좁혀졌다** — 컬럼 개수가 «안 바뀌는» 자리는
+ *   `columnPreservingValueTypeEntry`(아래)가 갈라 내고 그쪽은 in-place patch 로 열려 있다. 이 함수는
+ *   **여전히 GUI 의 전환 판정 단일 출처**이므로 «건드리지 않았다» — 좁히면 GUI 가 그 형상을 전환이 아닌
+ *   단순 update 로 흘려 `attrType` 이 안 따라가는 회귀가 된다(두 물음이 «같은 선»이 아니다).
  * ★같은 값 재전송(라운드트립 에코)은 변경이 아니므로 거짓이다(`attrType` 게이트의 에코 통과와 동형).
  */
 export declare function isStructuralTypeChange(attr: Pick<Attribute, 'attrType' | 'type'>, targetType: string, embeddables: EmbeddableCatalog): boolean;
+/**
+ * 이 타입 변경이 **컬럼 개수를 바꾸지 않는** ② 값 타입 재지정인가 — 맞으면 목적지 카탈로그 엔트리를,
+ * 아니면 `undefined` 를 돌려준다. AI(op) 경로가 이 자리를 **in-place `{type, attrType}` patch** 로
+ * 처리해도 되는지의 단일 출처다.
+ *
+ * ★**왜 필요했나**(2026-09-04 · 무인화 갭 ④): `isStructuralTypeChange` 는 *「목적지가 ② 임베더블」* 이기만
+ *   하면 참이라 **1필드 카탈로그 × 1컬럼 속성**까지 `attribute-type-conversion-unsupported`(reason
+ *   **`column-count`**)로 막았다 — 이름이 사유를 자칭하는데 **그 사유가 성립하지 않는 자리**다. 실측
+ *   근거: 값 타입 배치 **28자리 전량**이 그 형상이라 symbolic-ops 를 못 쓰고 raw `/ops` 로 우회했다.
+ *
+ * ★★**계약을 «id 보존»(in-place)으로 정한 근거 — 취향이 아니라 손실 논거다**: 같은 착지점을 GUI 는
+ *   삭제+추가로 내는데(새 속성 id), AI 의 어휘로 그걸 흉내 내면 **데이터가 사라진다** — `AttrSpec` 에
+ *   `order` 가 없어 자리가 맨 뒤로 밀리고, `EmbeddableColumnOverride` 에 `logicalName`·`dataType` 이 없어
+ *   **컬럼 논리명이 조용히 소실**되며(그 배치 실측 27/28 자리 보유), agent 경로엔 `survivingRefs` 가 없어
+ *   **인덱스 ref 가 끊긴다**. 컬럼 개수가 같으면 `dbAttrs` 를 **modelId 째 그대로** 두면 되므로 그 손실이
+ *   **전부 발생하지 않는다** ⇒ in-place 가 우월하고, 이 술어가 그 「같을 때」를 정의한다.
+ * ★**GUI 는 그대로 «전환»(새 id)이다** — 두 경로의 최종 «모델 상태»는 속성 modelId 를 빼면 같다.
+ *   같은 배치에 같은 id 가 `$pull`·`$push` 양쪽에 등장하면 병합 순서에 의존하므로(`convertAttributeType`
+ *   헤더) GUI 쪽이 id 를 새로 다는 것도 근거가 있고, 둘 다 각자 자리에서 옳다.
+ *
+ * 성립 조건 넷 — 하나라도 어긋나면 `undefined`(= 종전 거부 유지):
+ *  ① 실제 변경일 것(에코 제외) ② 출발이 **컬럼을 가진 값 속성**(`NORMAL`·`EMBED_PREDEF` — `convertAttributeType`
+ *  의 진입 규칙과 같다. `EMBED_OWN`·`EMBED_REF` 는 association 이 정체성, `RELATION_*` 은 컬럼이 관계 파생)
+ *  ③ 목적지가 **② 카탈로그**에 있을 것 ④ 그 필드 수가 **현재 `dbAttrs` 길이와 같을 것**.
+ *
+ * ⚠️**되돌림(② → `NORMAL`)은 여기서 열지 않는다** — 그 방향은 ③ predefined customtype 목적지에서
+ *   `seedPredefinedCustomTypeColumn` 이 컬럼 메타를 시드하는데(`convertAttributeType`), resolver 에는 그
+ *   카탈로그가 주입되지 않아 **AI 만 시드를 빠뜨린 채 착지**한다(= 조용한 비대칭). 열려면 그 카탈로그
+ *   주입이 선행이고, 그때까지는 거부가 정직하다.
+ * ⚠️**PK 카디널리티 게이트가 불필요해지는 것도 이 조건 덕분**이다 — `convertAttributeType` 이 막는 것은
+ *   *컬럼 개수가 바뀌는* PK(1→2 면 자식 FK 미러가 무너진다)이고, 여기는 정의상 개수가 같다.
+ */
+export declare function columnPreservingValueTypeEntry(attr: Pick<Attribute, 'attrType' | 'type' | 'dbAttrs'>, targetType: string, embeddables: EmbeddableCatalog): EmbeddableCatalogEntry | undefined;
 /**
  * ⑤ 파생 타입 커플링이 깨졌는가 — **`GroupCodeEnum` 과 `groupCode` 결합은 «항상 함께»**다(XOR 이면 깨짐).
  *