@g1cloud/entity-modeler-next 5.0.4 → 5.0.6

package/dist/core/attributeOrder.d.ts

@@ -8,6 +8,17 @@ import { Attribute, Entity } from './types';
 export declare function nextOrder(items: readonly {
     order: number;
 }[]): number;
+/**
+ * 재정렬 결과 순서 — 대상(`movingIds`)을 현재 상대 순서를 유지한 채 `toIndex`로 옮긴 배열.
+ * `toIndex`는 **대상을 모두 뺀 배열(rest) 기준 삽입 위치**다.
+ *
+ * 순수 함수로 뽑은 이유: 같은 산식을 세 곳이 쓴다 — `commands.reorderAttributes`/`reorderOperations`의
+ * apply, 그리고 **임베드 슬롯 정렬 전파**(`embedSlots.planEmbedSlotReorder` 호출부)가 커밋 전에
+ * "재정렬 후 순서"를 미리 알아야 한다. 각자 splice를 다시 쓰면 전파가 실제 재정렬과 어긋난다.
+ */
+export declare function reorderedSequence<T extends {
+    modelId: string;
+}>(items: readonly T[], movingIds: readonly string[], toIndex: number): T[];
 /** 물리 FK 컬럼을 가진 FK 여부 — derivedFrom(관계 파생) + dbAttrs(물리 컬럼) 보유. */
 export declare function isPhysicalFk(a: Attribute): boolean;
 /**

package/dist/core/embedSlots.d.ts

@@ -16,3 +16,44 @@ export interface EmbedSlotFill {
  * 남고 owner 슬롯을 비우는 것이 정상이라 제외한다(`controller.setEmbedCardinality`가 `dbAttrs: []`).
  */
 export declare function planEmbedSlotFill(model: LogicalModel, embeddableRef: ModelId, genId?: () => ModelId): EmbedSlotFill[];
+/** 한 사용처의 슬롯 재배치 계획 — 컨트롤러/resolver가 `updateAttribute { dbAttrs }`로 커밋한다. */
+export interface EmbedSlotReorder {
+    /** 표시 속성을 보유한 소유자 엔티티. */
+    entityId: ModelId;
+    /** `EMBED_OWN` 표시 속성. */
+    attributeId: ModelId;
+    /** 재배치 후 전체 슬롯 목록(같은 슬롯 객체들의 순서만 바뀐다 — 신규·삭제 없음). */
+    dbAttrs: DbColumn[];
+    /** 자리를 옮긴 슬롯 수(로그·테스트 가독용). */
+    moved: number;
+}
+/**
+ * 임베드 슬롯 **정렬 전파** — 임베더블 속성이 재정렬되면 사용처(owner) 슬롯도 같은 순열로 옮긴다.
+ * `planEmbedSlotFill`(꼬리 보충)의 순서 축 짝이다.
+ *
+ * ## 왜 가능한가 — 사후 복원은 불가지만 조작 시점엔 근거가 있다
+ * 슬롯↔소스 대응은 **위치(인덱스)뿐**이라(슬롯에 소스 링크가 없다) *이미 어긋난 뒤에는* 어느 슬롯이
+ * 어느 컬럼이었는지 복원할 수 없다 — 이 파일 헤더가 적어 둔 그 한계다. 그러나 **재정렬을 실행하는
+ * 시점에는 순열을 알 수 있다**: 임베더블 컬럼(`DbColumn.modelId`)이 재정렬 전후로 동일한 신원을
+ * 유지하므로, 전/후 평탄 순서를 컬럼 id로 짝지으면 슬롯을 옮길 자리가 유일하게 결정된다.
+ * ⇒ 저장 스키마에 소스 링크를 새로 심지 않고도 앞으로의 유입을 차단한다(예방이 본체 — 축적분은
+ * 아래 게이트가 보류하고 `CHK-JPA-21`이 계속 지목한다).
+ *
+ * ## 안전성 — 보충과 달리 충돌 게이트가 필요 없다
+ * 순열은 슬롯 **집합을 보존**한다(같은 객체들을 옮길 뿐). 따라서 그 엔티티의 실효 물리명 다중집합이
+ * 불변이고 `CHK-NAME-2`(물리명 중복)·DDL 컬럼 집합에 영향이 없다 — 보충이 새 이름을 상속시켜
+ * 충돌을 만들 수 있던 것과 성격이 다르다. 바뀌는 것은 *어느 override가 어느 소스 컬럼에 붙는가*이고,
+ * 그 대응이 바로 재정렬이 옮긴 것이다.
+ *
+ * ## 게이트 둘 — 확실할 때만 옮긴다
+ *  1. **순열일 때만**: `nextAttributeOrder`가 현재 속성 집합과 같아야 한다. 추가·삭제가 섞였으면
+ *     보충(꼬리) 축 소관이고, 위치 대응이 이번 조작 안에서 이미 흔들려 순열 근거가 없다.
+ *  2. **대응이 성립하던 사용처만**: 슬롯 수가 재정렬 전 선언 컬럼 수와 같아야 한다. 이미 뒤처진/앞선
+ *     사용처(축적 드리프트)는 인덱스 대응 자체가 깨져 있어 옮기면 **더 나빠진다**([[dont-invent-unknown-values]]
+ *     — 근거 없는 재배치는 추측이다). 그런 사용처는 `CHK-JPA-21`이 계속 지목한다.
+ *
+ * @param model 재정렬 **이전** 상태(현재 모델).
+ * @param embeddableRef 재정렬된 임베더블(사용처가 `embedded.embeddableRef`로 가리키는 그 엔티티).
+ * @param nextAttributeOrder 재정렬 후 임베더블 속성 순서(전체 — `reorderedSequence` 산출).
+ */
+export declare function planEmbedSlotReorder(model: LogicalModel, embeddableRef: ModelId, nextAttributeOrder: readonly ModelId[]): EmbedSlotReorder[];

package/dist/editor/commandPlans.d.ts

@@ -69,6 +69,15 @@ export declare function withEntityAttributes(logical: LogicalModel, entityId: Mo
  * 트리거를 한 곳에만 두면 되고, 서브명령이 같은 composite에 실려 **undo가 원자적**이다.
  */
 export declare function cascadeCommands(futureLogical: LogicalModel, parentId: ModelId, removed: RemovedAttributes): Command[];
+/**
+ * 임베더블 속성 재정렬이 사용처 슬롯으로 번지는 서브명령(`core/embedSlots.planEmbedSlotReorder`).
+ * 재정렬 커맨드와 **같은 composite**에 실어 undo가 원자적이게 한다(보충이 `cascadeCommands`에 실리는
+ * 것과 같은 규율). 대상이 임베더블이 아니거나 게이트에 걸리면 빈 배열 = 재정렬만 실행된다.
+ *
+ * 순서 산식은 `reorderedSequence` 단일 출처를 쓴다 — 커맨드가 apply에서 쓰는 그 함수라 계획과 실행이
+ * 어긋날 수 없다(여기서 splice를 다시 쓰면 그 지점이 드리프트 후보가 된다).
+ */
+export declare function embedSlotReorderCommands(logical: LogicalModel, entityId: ModelId, attrIds: ModelId[], toIndex: number): Command[];
 /**
  * "자식의 FK 집합이 직접 바뀌는" 트리거(관계 삭제·identifying 토글)용 연쇄 서브명령.
  * 1) seed 자식을 직접 reconcile(FK 증감/플립), 2) 그 변화를 적용한 상태로 후손 cascade.