Editing Openai/691b0f10-2f54-8005-9100-81f83803b484 (section)

==== ### ====

<syntaxhighlight lang="python">class AdminClientVehicleCreateSchema(BaseModel):
    ...
    client_id: UUID
    organization_id: UUID | None
    vehicle_number: Annotated[str, constr(min_length=1, max_length=50)]
    type: VehicleTypeEnum | None
    status: VehicleStatusEnum = VehicleStatusEnum.active
    model_name: str | None = Field(..., max_length=100)
    model_year: int | None
    access_scopes: list[str] | None

</syntaxhighlight>

좋은 점:
* ClientVehicleCreateSchema와 구조가 거의 평행이라 읽기 쉽고, 도메인 감각도 맞아요.
* vehicle_number에 길이 제약 넣어둔 것도 좋습니다.

고려해 볼 점:
# access_scopes 제약 - 현재는 자유로운 list[str]라서, FE나 다른 서비스에서 오타/케이스 문제로 꼬일 여지가 있습니다. - 나중에라도 enum-ish한 레벨로 묶고 싶다면: - 최소한 상수 리스트(ALLOWED_ACCESS_SCOPES = {"dispatch", "weighing", ...})로 검증하는 validator를 하나 붙이는 것도 옵션입니다.
# 기존 스키마와의 코드 중복 최소화 - ClientVehicleCreateSchema와 필드 구성이 많이 겹칩니다. - 나중에 필드 하나를 변경할 일이 생기면 둘 다 수정해야 해서 살짝 부채가 될 수 있어요. - 예를 들면: </code>`<code>python class BaseClientVehicleCreate(BaseModel):     vehicle_number: ...     type: ...     status: ...     model_name: ...     model_year: ... class ClientVehicleCreateSchema(BaseClientVehicleCreate):     client_id: UUID | None = Field(None, ...?)  # 기존 정의 따라 class AdminClientVehicleCreateSchema(BaseClientVehicleCreate):     client_id: UUID = ...     organization_id: UUID | None = ...     access_scopes: list[str] | None = ... </code>`<code> - 지금 당장 필수는 아니고, “한 번 더 같은 작업 생기면 리팩터링 후보” 정도로 보입니다.

==== <syntaxhighlight lang="python">stmt = select(VehicleOrgAccess).where( ====
    VehicleOrgAccess.vehicle_id == vehicle_id,
    VehicleOrgAccess.organization_id == organization_id,
)
result = await self.session.execute(stmt)
access = result.scalar_one_or_none()

if access is None:
    access = VehicleOrgAccess(
        vehicle_id=vehicle_id,
        organization_id=organization_id,
        scopes=scopes or None,
        created_by=created_by,
    )
    self.session.add(access)
else:
    access.is_deleted = False
    access.deleted_at = None
    if scopes:
        access.scopes = scopes

await self.session.flush()
if commit and self.session.in_transaction():
    await self.session.commit()

</syntaxhighlight>

좋은 점:
* soft-delete 복구 + scopes 갱신 흐름이 명확하고, 테스트로도 잘 검증되어 있습니다.
* commit=False로 boundary와 함께 쓸 수 있게 한 패턴도 깔끔해요.

확인/개선 포인트:
# 트랜잭션 처리 패턴 통일성 - 여기서 if commit and self.session.in_transaction(): 패턴을 쓰고 있는데, - 같은 서비스 내 다른 메서드들이 어떤 패턴을 쓰는지에 따라: - commit/rollback 책임이 service에 있는지, - 아니면 항상 boundary에 있는지, 를 통일해 두는 게 이해하기 쉬울 것 같습니다. - 이미 다른 메서드들도 같은 패턴이라면 OK, 아니라면 “service는 flush까지만, commit/rollback은 boundary에서만” 규칙으로 정리하는 것도 방법.
# 중복/레이스 이슈 - DB 레벨에서 (vehicle_id, organization_id)에 unique 인덱스가 없으면, - 이 함수가 동시에 두 번 호출될 때 둘 다 access is None이 되어 중복 insert 가능성이 있습니다. - 이미 unique constraint가 있다면 OK고, 없다면: - 나중에라도 unique index + IntegrityError 처리로 감싸는 선택지도 고려할 수 있겠습니다.
# 예외 타입 - SQLAlchemyError를 APIException(INTERNAL_ERROR)로 감싸는 건 API 레이어 입장에서는 적절합니다. - 다만 이 서비스가 내부에서만 쓰이는지, 다른 서비스/배치에서도 호출되는지에 따라: - 내부에서는 APIException보다 별도 domain-level 예외가 더 자연스러울 수도 있고, - 이미 이 서비스 전체가 “API용”이라는 컨벤션이면 지금처럼 두셔도 괜찮습니다.

==== <syntaxhighlight lang="python">return await run_with_session_boundary( ====
    db,
    _operation,
    logger=logger,
    log_message="클라이언트 차량 대리 등록 실패",
    error_detail="거래처 차량 등록 중 오류가 발생했습니다.",
    log_extra={
        "route": "/api/v1/admin/subscriber/client-vehicle/",
        "actor_id": str(current_user.id),
        "entity_id": str(payload.client_id),
    },
)

</syntaxhighlight>
* 메시지/한글 에러/route/actor_id 구조 모두 기존 정책을 잘 따라가고 있습니다.
* entity_id를 client_id로 둔 것도 “이 엔드포인트의 논리적 대상은 client와 vehicle의 관계”라서 납득은 돼요.

추가로 조금만 욕심을 내보자면:
* log_extra에 target_org_id 정도를 같이 넣어두면, - 나중에 사고 분석할 때 “어느 org에 대해 시도했는가”가 바로 보여서 디버깅이 더 편할 것 같습니다. - 예: </code>`<code>python "target_org_id": str(target_org_id), "vehicle_registration_source": "subscriber_proxy", </code>``