2026-07-07 세션 — orderpaper 자재관리 탭 기능 추가·번호정리·성능 근본해결
pfs(Flask/MySQL on EC2) field/orderpaper 자재관리 탭(orderpaper_material_mgmt.js) 집중 세션. 기능 4건 + orderpaper_no 재번호 + 성능 저하 3연속 근본진단·해결까지 전부 운영배포. domain:orderpaper svc:pfs-material.
논의·대안
- 자재관리 탭 기능 4건(+페페 추가지시 2): 행별 삭제(=숨김 remove_yn=1)·품명/규격 편집·발주량 숫자만+단위 새 컬럼·품명 15TT→15T 정규화. 추가지시=삭제버튼 맨왼쪽·확인없이 즉시. 히스토리는 누적사용량 우측 📜 아이콘으로 이동(규격셀=편집전용).
- orderpaper_no 재번호: 1500행인데 no가 575390까지 팜. 원인=동기화
INSERT..ON DUPLICATE가 매회 AUTO_INCREMENT 낭비. 페페 "1부터 재시작, 필요하면 데이터 지우고 재동기화"→소실규모 실측(재고1297·상태693 등 사용자편집 전부 소실) 보고→페페 "번호만 재부여"(편집 보존) 채택. - 성능 저하 진단(3연타): 페페 "삭제 후·로드도 느림·컴퓨터 전체 느려짐". 로컬/테스트로는 재현 안 돼 여러 번 헛짚음. 페페가 "운영을 사용자 크롬으로 테스트하라" 지시가 결정적 — 실환경 재현으로 원인 확정. JS heap·SQL·서버응답은 다 정상이라 그걸로는 못 잡음.
결정
- 삭제=remove_yn=1(동기화 안 되살림), 편집은
*_user컬럼 COALESCE 오버라이드(동기화 보존). - 번호정리는 전체삭제 아닌 PK만 1..N 재부여(백업+트랜잭션+offset 2패스+usage_history 참조 갱신).
- 성능은 대형 테이블 3대 원인 순차 제거: ①삭제 시 전체 innerHTML 재빌드→tr만 제거 ②폼요소 상시렌더(2241개)→클릭 시 지연생성 ③table-layout:auto 전체 재측정→fixed+colgroup.
산출물·커밋
- DB(운영 RDS): orderpaper ADD COLUMN item_name_user/spec_user/unit_user(patch39), orderpaper_no 1..1500 재번호(AUTO_INCREMENT=1501), 백업테이블 2개 보존.
- 백엔드: dao/service/controller PATCH
/item-name·/spec·/unit, all-items COALESCE. 동기화 근본수정(orderpaper_sync.py신규만 INSERT·기존 UPDATE 분리). - 프론트:
orderpaper_material_mgmt.js(지연렌더 editStart/mtStart/_commit/_commitUsed/bindEdit, 낙관삭제 delItem),.css(table-layout:fixed·mm-edit·mm-edit-in). 캐시버스터?v=20260707g. - 커밋 체인(운영): 자재관리 4기능
75b8ff0→ CSS정렬a5ce41d→ 삭제최적화c3e8a37·94c6fb4·b0bc891(증상완화) → 재번호4748172(master) → 폼요소 지연렌더7819c63→ table fixed93dc5f5. 승인: DEPLOY-20260706-2ZPM·20260707-RM6T·R94Y·7FND·E8G8·ZN7E·36RQ·HKVV.
다음
- 페페 육안 확인(Ctrl+Shift+R로 v20260707g). 여전히 느리면 추가 진단(3대 원인은 제거됨).
- 운영 백업테이블 2개 정리(며칠 후 페페 승인 시 DROP).
관계
- 주제 그룹: pfs-material
- 관련 문서: pfs handoff.md, [[innerHTML-rebuild-renderer-memory-spike]] 메모리