#Step 01 — 환경 구축과 첫 쿼리

// selectFrom 이 아니라 selct — 알파벳 하나가 빠졌습니다
String jpql = "selct c from Customer c where c.grade = :grade";

List<Customer> result = em.createQuery(jpql, Customer.class)
        .setParameter("grade", Grade.VIP)
        .getResultList();

// 테스트를 실행하면
@Test
void 오타난_JPQL() {
    String jpql = "selct c from Customer c where c.grade = :grade";
    em.createQuery(jpql, Customer.class).setParameter("grade", Grade.VIP).getResultList();
}

List<Customer> result = queryFactory
        .selctFrom(customer)                       // 오타
        .where(customer.grade.eq(Grade.VIP))
        .fetch();

.where(customer.grde.eq(Grade.VIP))   // grade 가 아니라 grde

.where(customer.points.eq("VIP"))     // points 는 Integer 인데 String 을 넣음

package com.example.shop.config;

import com.querydsl.jpa.impl.JPAQueryFactory;
import jakarta.persistence.EntityManager;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Configuration
public class QuerydslConfig {

    @Bean
    public JPAQueryFactory jpaQueryFactory(EntityManager em) {
        return new JPAQueryFactory(em);
    }
}

@Test
void 주입된_EntityManager의_정체() {
    System.out.println(em.getClass().getName());
    System.out.println(em instanceof jakarta.persistence.EntityManager);
}

@PersistenceContext
private EntityManager em;      // 이것도 SharedEntityManagerCreator 프록시

package com.example.shop.step01;

import com.querydsl.jpa.impl.JPAQueryFactory;
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.transaction.annotation.Transactional;

import java.util.List;

import static com.example.shop.entity.QCustomer.customer;   // ★ static import

@SpringBootTest
@Transactional
class FirstQueryTest {

    @Autowired
    JPAQueryFactory queryFactory;

    @Test
    void VIP_고객_조회() {
        List<Customer> result = queryFactory
                .selectFrom(customer)
                .where(customer.grade.eq(Grade.VIP))
                .fetch();

        result.forEach(c -> System.out.println(c.getName() + " / " + c.getCity()));
    }
}

// 이름만 뽑을 때는 축약할 수 없습니다
List<String> names = queryFactory
        .select(customer.name)
        .from(customer)
        .where(customer.grade.eq(Grade.VIP))
        .fetch();

Customer one = queryFactory.selectFrom(customer)
        .where(customer.email.eq("seojun.kim@example.com"))
        .fetchOne();

queryFactory.selectFrom(customer).where(customer.grade.eq(Grade.VIP)).fetch();

// JPQL
em.createQuery("select c from Customer c where c.grade = :grade", Customer.class)
  .setParameter("grade", Grade.VIP)
  .getResultList();

// QueryDSL
queryFactory.selectFrom(customer)
        .where(customer.grade.eq(Grade.VIP))
        .fetch();

// JPQL
em.createQuery("""
        select c from Customer c
        where c.points >= :min
        order by c.name asc
        """, Customer.class)
  .setParameter("min", 5000)
  .getResultList();

// QueryDSL
queryFactory.selectFrom(customer)
        .where(customer.points.goe(5000))
        .orderBy(customer.name.asc())
        .fetch();

// JPQL — % 를 직접 붙여야 합니다
em.createQuery("select c from Customer c where c.name like :kw", Customer.class)
  .setParameter("kw", "%지%")
  .getResultList();

// QueryDSL — contains 가 % 를 붙여 줍니다
queryFactory.selectFrom(customer)
        .where(customer.name.contains("지"))
        .fetch();

// JPQL
em.createQuery("select c from Customer c where c.phone is null", Customer.class)
  .getResultList();

// QueryDSL
queryFactory.selectFrom(customer)
        .where(customer.phone.isNull())
        .fetch();

// JPQL
em.createQuery("""
        select c.city, count(c)
        from Customer c
        group by c.city
        order by count(c) desc
        """, Object[].class)
  .getResultList();

// QueryDSL
queryFactory
        .select(customer.city, customer.count())
        .from(customer)
        .groupBy(customer.city)
        .orderBy(customer.count().desc())
        .fetch();

JPAQuery<Customer> query = queryFactory
        .selectFrom(customer)
        .where(customer.grade.eq(Grade.VIP)
                .and(customer.points.goe(5000)));

System.out.println(query.toString());     // 아직 실행 안 함
List<Customer> result = query.fetch();    // 여기서 실행

// ✗ 이런 API 자체가 없습니다
queryFactory.selectFrom( <서브쿼리> )

@Service
public class CustomerService {

    @PersistenceContext
    private EntityManager em;

    public List<Customer> findVips() {
        JPAQueryFactory queryFactory = new JPAQueryFactory(em);   // 호출마다 생성
        return queryFactory.selectFrom(customer)
                .where(customer.grade.eq(Grade.VIP))
                .fetch();
    }
}

// 고친 코드
@Service
@RequiredArgsConstructor
public class CustomerService {

    private final JPAQueryFactory queryFactory;   // 빈 주입

    public List<Customer> findVips() {
        return queryFactory.selectFrom(customer)
                .where(customer.grade.eq(Grade.VIP))
                .fetch();
    }
}

@Component
public class BadQuerySupport {

    private final JPAQueryFactory queryFactory;

    public BadQuerySupport(EntityManagerFactory emf) {
        // ✗ 프록시가 아니라 진짜 EntityManager 를 만들어 싱글턴에 고정
        this.queryFactory = new JPAQueryFactory(emf.createEntityManager());
    }
}

public List<Order> findOrdersWithCustomerName() {
    List<Order> orders = queryFactory.selectFrom(order).limit(5).fetch();
    // 트랜잭션 없음 → 조회 직후 영속성 컨텍스트가 닫힘
    return orders;
}

// 호출한 쪽에서
orders.get(0).getCustomer().getName();

package com.example.shop.step01;

import com.example.shop.entity.Customer;
import com.example.shop.entity.Grade;
import com.querydsl.core.NonUniqueResultException;
import com.querydsl.jpa.impl.JPAQuery;
import com.querydsl.jpa.impl.JPAQueryFactory;
import jakarta.persistence.EntityManager;
import jakarta.persistence.PersistenceContext;
import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.transaction.annotation.Transactional;

import java.util.List;

import static com.example.shop.entity.QCustomer.customer;
import static org.assertj.core.api.Assertions.assertThat;
import static org.assertj.core.api.Assertions.assertThatThrownBy;

/**
 * Step 01 — 환경 구축과 첫 쿼리
 *
 * 본문 1-1 ~ 1-9 의 모든 예제를 절 번호 주석과 함께 담았습니다.
 *
 * 실행:
 *   ./gradlew test --tests 'com.example.shop.step01.Practice'
 *
 * ★ 전제 — application.yml 에 SQL 로그 설정이 되어 있어야 합니다.
 *   logging:
 *     level:
 *       org.hibernate.SQL: debug
 *       org.hibernate.orm.jdbc.bind: trace
 *       org.hibernate.orm.query: trace
 *   spring:
 *     jpa:
 *       properties:
 *         hibernate:
 *           format_sql: true
 *
 * 이 설정이 없으면 콘솔에 아무것도 안 나오고, 이 스텝의 실습은 의미가 없어집니다.
 */
@SpringBootTest
@Transactional
class Practice {

    @Autowired
    JPAQueryFactory queryFactory;

    @PersistenceContext
    EntityManager em;

    // =====================================================================
    // [1-1] QueryDSL 이란 — 오타가 런타임에야 터진다
    // =====================================================================

    /**
     * 키워드 오타(selct)는 컴파일을 통과하고 실행 시점에 SyntaxException 을 던집니다.
     * 이 테스트는 "예외가 나는 것"을 검증하므로 초록불이 정상입니다.
     */
    @Test
    @DisplayName("[1-1] 문자열 JPQL 의 키워드 오타는 런타임에 터진다")
    void 오타난_JPQL_은_런타임에_터진다() {
        String jpql = "selct c from Customer c where c.grade = :grade";   // select 오타

        assertThatThrownBy(() ->
                em.createQuery(jpql, Customer.class)
                        .setParameter("grade", Grade.VIP)
                        .getResultList()
        ).satisfies(e -> {
            System.out.println("예외 클래스 : " + e.getClass().getName());
            System.out.println("메시지     : " + e.getMessage());
        });
    }

    /**
     * 필드명 오타는 파싱은 통과하고 "의미 해석" 단계에서 실패합니다.
     * 그래서 SyntaxException 이 아니라 SemanticException 이 납니다.
     */
    @Test
    @DisplayName("[1-1] 필드명 오타는 SemanticException")
    void 필드명_오타는_SemanticException() {
        String jpql = "select c from Customer c where c.grde = :grade";   // grade 오타

        assertThatThrownBy(() ->
                em.createQuery(jpql, Customer.class)
                        .setParameter("grade", Grade.VIP)
                        .getResultList()
        ).satisfies(e -> System.out.println("예외 클래스 : " + e.getClass().getName()));
    }

    /**
     * 같은 실수를 QueryDSL 로 하면 아래 코드는 애초에 컴파일되지 않습니다.
     * 주석을 풀고 ./gradlew compileTestJava 를 돌려 직접 확인해 보세요.
     *
     *   queryFactory.selctFrom(customer)                   // cannot find symbol: selctFrom
     *   queryFactory.selectFrom(customer)
     *           .where(customer.grde.eq(Grade.VIP))        // cannot find symbol: grde
     *   queryFactory.selectFrom(customer)
     *           .where(customer.points.eq("VIP"))          // incompatible types
     */

    // =====================================================================
    // [1-4] JPAQueryFactory 빈 등록 — EntityManager 는 프록시다
    // =====================================================================

    /**
     * 스프링이 주입하는 EntityManager 는 SharedEntityManagerCreator 가 만든 프록시입니다.
     * 실제 세션(SessionImpl)이 아니라, "지금 스레드의 세션을 찾아 위임하는" 객체입니다.
     * 그래서 싱글턴 JPAQueryFactory 가 이 프록시를 필드로 붙들어도 안전합니다.
     */
    @Test
    @DisplayName("[1-4] 주입된 EntityManager 는 프록시다")
    void 주입된_EntityManager의_정체() {
        System.out.println("클래스명 : " + em.getClass().getName());
        System.out.println("인터페이스 만족 : " + (em instanceof EntityManager));

        // jdk.proxy2.$Proxy214 처럼 $Proxy 가 들어가면 정상 (숫자는 매 실행 다릅니다)
        assertThat(em.getClass().getName()).contains("Proxy");
    }

    /**
     * unwrap 으로 프록시 뒤의 실제 세션을 꺼내 볼 수 있습니다.
     * 이건 확인용이며, 애플리케이션 코드에서 이렇게 꺼내 쓰면 안 됩니다.
     */
    @Test
    @DisplayName("[1-4] 프록시 뒤의 실제 세션")
    void 프록시_뒤의_실제_세션() {
        Object session = em.unwrap(org.hibernate.Session.class);
        System.out.println("실제 세션 : " + session.getClass().getName());
        // org.hibernate.internal.SessionImpl
    }

    // =====================================================================
    // [1-5] 첫 쿼리 — selectFrom
    // =====================================================================

    /**
     * 생성 SQL:
     *   select c1_0.customer_id, c1_0.city, c1_0.created_at, c1_0.email,
     *          c1_0.grade, c1_0.name, c1_0.phone, c1_0.points
     *   from customers c1_0
     *   where c1_0.grade = ?
     * 바인딩: [1] VIP  → 4건 (김서준, 류하나, 정  훈, 배채영)
     */
    @Test
    @DisplayName("[1-5] VIP 고객 조회 — selectFrom")
    void VIP_고객_조회() {
        List<Customer> result = queryFactory
                .selectFrom(customer)
                .where(customer.grade.eq(Grade.VIP))
                .fetch();

        result.forEach(c -> System.out.println(c.getName() + " / " + c.getCity()));
        assertThat(result).hasSize(4);
    }

    /**
     * 조회 대상과 from 이 다르면 selectFrom 축약을 쓸 수 없습니다.
     * 생성 SQL: select c1_0.name from customers c1_0 where c1_0.grade = ?
     */
    @Test
    @DisplayName("[1-5] 이름만 조회 — select + from 은 나눠 쓴다")
    void 이름만_조회() {
        List<String> names = queryFactory
                .select(customer.name)
                .from(customer)
                .where(customer.grade.eq(Grade.VIP))
                .fetch();

        System.out.println(names);
        assertThat(names).hasSize(4);
    }

    /**
     * fetchOne() 은 유니크 제약이 있는 컬럼으로 조회할 때만 안전합니다.
     */
    @Test
    @DisplayName("[1-5] fetchOne — 유니크 컬럼(email)으로 단건 조회")
    void 단건_조회() {
        Customer one = queryFactory
                .selectFrom(customer)
                .where(customer.email.eq("seojun.kim@example.com"))
                .fetchOne();

        System.out.println("조회 결과 : " + (one == null ? "null" : one.getName()));
    }

    // =====================================================================
    // [1-6] SQL 로그 보는 법
    // =====================================================================

    /**
     * 이 테스트는 아무것도 단언하지 않습니다. 콘솔을 눈으로 보라는 테스트입니다.
     *
     * 아래 두 줄이 모두 보여야 이후 스텝을 정상적으로 진행할 수 있습니다.
     *   org.hibernate.SQL              : select ... from customers c1_0 where ...
     *   org.hibernate.orm.jdbc.bind    : binding parameter (1:VARCHAR) <- [VIP]
     *
     * 파라미터 줄이 안 보인다면 Hibernate 5 용 카테고리
     * (org.hibernate.type.descriptor.sql.BasicBinder) 를 설정한 것입니다.
     * Hibernate 6 에서는 org.hibernate.orm.jdbc.bind 를 써야 합니다.
     */
    @Test
    @DisplayName("[1-6] 로그 설정 확인 — 콘솔을 눈으로 볼 것")
    void 로그_설정_확인() {
        queryFactory.selectFrom(customer)
                .where(customer.grade.eq(Grade.VIP))
                .fetch();

        System.out.println("↑ 위 콘솔에 hibernate.SQL 과 binding parameter 가 둘 다 보이는지 확인하세요.");
    }

    // =====================================================================
    // [1-7] JPQL vs QueryDSL 대조
    // =====================================================================

    @Test
    @DisplayName("[1-7] ① VIP 고객 — JPQL / QueryDSL 결과 동일")
    void 대조_VIP_고객() {
        List<Customer> byJpql = em.createQuery(
                        "select c from Customer c where c.grade = :grade", Customer.class)
                .setParameter("grade", Grade.VIP)
                .getResultList();

        List<Customer> byQuerydsl = queryFactory
                .selectFrom(customer)
                .where(customer.grade.eq(Grade.VIP))
                .fetch();

        assertThat(byQuerydsl).hasSameSizeAs(byJpql);
    }

    /**
     * 생성 SQL: ... where c1_0.points >= ? order by c1_0.name asc
     */
    @Test
    @DisplayName("[1-7] ② 포인트 5000 이상, 이름순")
    void 대조_포인트_정렬() {
        List<Customer> result = queryFactory
                .selectFrom(customer)
                .where(customer.points.goe(5000))
                .orderBy(customer.name.asc())
                .fetch();

        result.forEach(c -> System.out.println(c.getName() + " " + c.getPoints()));
    }

    /**
     * contains 는 %키워드% 를 자동으로 만들고 escape '!' 까지 붙여 줍니다.
     * 생성 SQL: ... where c1_0.name like ? escape '!'   /  바인딩 [1] %지%
     */
    @Test
    @DisplayName("[1-7] ③ 이름 부분 일치 — contains 는 escape 를 붙인다")
    void 대조_이름_부분일치() {
        List<Customer> result = queryFactory
                .selectFrom(customer)
                .where(customer.name.contains("지"))
                .fetch();

        result.forEach(c -> System.out.println(c.getName()));
        assertThat(result).hasSize(2);      // 안지수, 한지호
    }

    /**
     * 생성 SQL: ... where c1_0.phone is null   → 3건
     */
    @Test
    @DisplayName("[1-7] ④ 전화번호가 없는 고객")
    void 대조_전화번호_null() {
        List<Customer> result = queryFactory
                .selectFrom(customer)
                .where(customer.phone.isNull())
                .fetch();

        result.forEach(c -> System.out.println(c.getName()));
        assertThat(result).hasSize(3);
    }

    /**
     * 생성 SQL:
     *   select c1_0.city, count(c1_0.customer_id)
     *   from customers c1_0 group by c1_0.city order by count(c1_0.customer_id) desc
     */
    @Test
    @DisplayName("[1-7] ⑤ 도시별 고객 수 — Tuple 로 받는다")
    void 대조_도시별_고객수() {
        queryFactory
                .select(customer.city, customer.count())
                .from(customer)
                .groupBy(customer.city)
                .orderBy(customer.count().desc())
                .fetch()
                .forEach(t -> System.out.println(
                        t.get(customer.city) + "  " + t.get(customer.count())));
    }

    // =====================================================================
    // [1-8] QueryDSL 이 만드는 것은 JPQL 이지 SQL 이 아니다
    // =====================================================================

    /**
     * 출력 순서가 곧 변환 순서입니다.
     *   ① toString()  → JPQL   : select customer from Customer customer where ...
     *   ② fetch()     → SQL    : select c1_0.customer_id, ... from customers c1_0 where ...
     *
     * 차이 3가지:
     *   - 별칭     : customer (Q타입 변수명)  vs  c1_0 (Hibernate 생성)
     *   - from 대상 : Customer (클래스명)      vs  customers (테이블명)
     *   - 파라미터 : ?1, ?2 (번호 있음)        vs  ?, ? (JDBC 자리표시자)
     */
    @Test
    @DisplayName("[1-8] JPQL 과 SQL 을 나란히 본다")
    void JPQL과_SQL을_나란히() {
        JPAQuery<Customer> query = queryFactory
                .selectFrom(customer)
                .where(customer.grade.eq(Grade.VIP)
                        .and(customer.points.goe(5000)));

        System.out.println("===== JPQL (toString, 아직 실행 안 함) =====");
        System.out.println(query.toString());

        System.out.println("===== SQL (아래 hibernate.SQL 로그) =====");
        List<Customer> result = query.fetch();

        result.forEach(c -> System.out.println(c.getName() + " " + c.getPoints()));
    }

    /**
     * JPQL 이 못 하는 것은 QueryDSL 도 못 합니다.
     * from 절 서브쿼리(인라인 뷰)는 JPQL 명세에 없으므로 API 자체가 존재하지 않습니다.
     * Step 07 에서 이 벽과 우회로를 다룹니다.
     */
    @Test
    @DisplayName("[1-8] from 절 서브쿼리는 API 자체가 없다")
    void from절_서브쿼리는_불가능() {
        // queryFactory.selectFrom( <서브쿼리> )   ← 이런 오버로드가 없습니다
        System.out.println("JPQL 명세에 인라인 뷰가 없으므로 QueryDSL(JPA) 에도 없습니다.");
    }

    // =====================================================================
    // [1-9] 함정
    // =====================================================================

    /**
     * fetchOne() 은 결과가 2건 이상이면 NonUniqueResultException 을 던집니다.
     * 서울 고객은 9명이므로 반드시 터집니다.
     */
    @Test
    @DisplayName("[1-9] fetchOne 은 2건 이상이면 터진다")
    void fetchOne_은_2건이면_터진다() {
        assertThatThrownBy(() ->
                queryFactory.selectFrom(customer)
                        .where(customer.city.eq("서울"))
                        .fetchOne()
        ).isInstanceOf(NonUniqueResultException.class)
         .satisfies(e -> System.out.println("메시지 : " + e.getMessage()));
    }

    /**
     * 안전한 대안 ① — fetchFirst() 는 limit(1) 을 붙여 첫 건만 가져옵니다.
     * 생성 SQL 끝에 limit ? 가 붙습니다.
     */
    @Test
    @DisplayName("[1-9] 대안 ① fetchFirst")
    void 대안_fetchFirst() {
        Customer first = queryFactory.selectFrom(customer)
                .where(customer.city.eq("서울"))
                .orderBy(customer.id.asc())
                .fetchFirst();

        System.out.println("첫 건 : " + (first == null ? "null" : first.getName()));
    }

    /**
     * 안전한 대안 ② — fetch() 로 받아 크기를 직접 검사합니다.
     * "몇 건 나왔는지"를 코드가 알고 있으므로 예외 대신 분기로 처리할 수 있습니다.
     */
    @Test
    @DisplayName("[1-9] 대안 ② fetch 후 size 검사")
    void 대안_fetch_후_size검사() {
        List<Customer> found = queryFactory.selectFrom(customer)
                .where(customer.city.eq("서울"))
                .fetch();

        System.out.println("건수 : " + found.size());
        if (found.size() == 1) {
            System.out.println("단건 : " + found.get(0).getName());
        } else {
            System.out.println("단건이 아니므로 별도 처리 (예외 아님)");
        }
    }

    /**
     * 함정 ③ — 조회 전용 메서드에 트랜잭션이 없으면 LazyInitializationException.
     * 이 클래스는 @Transactional 이라 여기서는 정상 동작합니다.
     * 트랜잭션을 떼고 같은 코드를 호출하면 프록시 초기화에서 터집니다.
     */
    @Test
    @DisplayName("[1-9] 지연 로딩은 트랜잭션 안에서만 안전하다")
    void 지연로딩은_트랜잭션_안에서만() {
        Customer c = queryFactory.selectFrom(customer)
                .where(customer.grade.eq(Grade.VIP))
                .fetchFirst();

        // @Transactional 덕분에 세션이 살아 있어 orders 프록시를 초기화할 수 있습니다.
        System.out.println(c.getName() + " 의 주문 수 : " + c.getOrders().size());
    }
}

package com.example.shop.step01;

import com.example.shop.entity.Customer;
import com.example.shop.entity.Grade;
import com.querydsl.jpa.impl.JPAQuery;
import com.querydsl.jpa.impl.JPAQueryFactory;
import jakarta.persistence.EntityManager;
import jakarta.persistence.PersistenceContext;
import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.transaction.annotation.Transactional;

import java.util.List;

import static com.example.shop.entity.QCustomer.customer;

/**
 * Step 01 — 연습문제 (6문제)
 *
 * 각 문제의 "여기에 작성:" 자리를 채우세요.
 * 정답과 해설은 Solution.java 에 있습니다. 먼저 직접 풀어 보세요.
 *
 * 실행:
 *   ./gradlew test --tests 'com.example.shop.step01.Exercise'
 */
@SpringBootTest
@Transactional
class Exercise {

    @Autowired
    JPAQueryFactory queryFactory;

    @PersistenceContext
    EntityManager em;

    // =====================================================================
    // 문제 1. 오타의 발견 시점 비교
    //
    // (1) 아래 JPQL 은 필드명이 c.grade 가 아니라 c.grde 로 잘못돼 있습니다.
    //     이 쿼리를 실행해서 어떤 예외가 나는지 확인하고,
    //     예외 클래스명과 메시지를 콘솔에 출력하세요.
    //     (예외를 삼키지 말고 반드시 출력할 것. 무엇이 어디서 터지는지 보는 게 목적입니다.)
    //
    // (2) 그다음 같은 쿼리를 QueryDSL 로 옮겨 쓰되,
    //     customer.grde 라고 오타를 내 보고 컴파일이 실패하는 것을 확인하세요.
    //     확인한 뒤에는 주석 처리해 두세요(그래야 나머지 테스트가 돌아갑니다).
    //
    // (3) 두 오타가 발견되는 "시점"이 어떻게 다른지 아래 주석에 한 줄로 적으세요.
    //     답:
    // =====================================================================
    @Test
    @DisplayName("문제 1. 오타의 발견 시점 비교")
    void 문제1_오타의_발견시점() {
        String jpql = "select c from Customer c where c.grde = :grade";

        // 여기에 작성:

    }

    // =====================================================================
    // 문제 2. 잘못된 build.gradle 판정
    //
    // 아래 4개의 의존성 조각에 대해, 각각 어떤 결과가 나오는지 판정하고
    // 근거를 주석으로 적으세요. 코드를 실행하는 문제가 아니라 판정 문제입니다.
    //
    // 보기:
    //   (A) 빌드 실패 — 의존성 해결 단계에서
    //   (B) 빌드 성공하지만 Q타입이 생성되지 않음
    //   (C) 빌드 성공하지만 런타임에 실패
    //   (D) 정상
    //
    // ---------------------------------------------------------------------
    // (a)
    //   implementation      'io.github.openfeign.querydsl:querydsl-jpa:6.12:jakarta'
    //   annotationProcessor 'io.github.openfeign.querydsl:querydsl-apt:6.12:jpa'
    //   판정:        근거:
    //
    // (b)
    //   implementation      'io.github.openfeign.querydsl:querydsl-jpa:6.12'
    //   annotationProcessor 'io.github.openfeign.querydsl:querydsl-apt:6.12'
    //   판정:        근거:
    //
    // (c)
    //   implementation      'com.querydsl:querydsl-jpa:5.0.0'
    //   annotationProcessor 'com.querydsl:querydsl-apt:5.0.0'
    //   판정:        근거:
    //
    // (d)
    //   implementation      'io.github.openfeign.querydsl:querydsl-jpa:6.12'
    //   implementation      'io.github.openfeign.querydsl:querydsl-core:6.12'
    //   annotationProcessor 'io.github.openfeign.querydsl:querydsl-apt:6.12:jpa'
    //   annotationProcessor 'jakarta.persistence:jakarta.persistence-api'
    //   annotationProcessor 'jakarta.annotation:jakarta.annotation-api'
    //   판정:        근거:
    // =====================================================================
    @Test
    @DisplayName("문제 2. build.gradle 판정 (주석으로 답을 적는 문제)")
    void 문제2_의존성_판정() {
        System.out.println("위 주석에 판정과 근거를 적었는지 확인하세요.");
    }

    // =====================================================================
    // 문제 3. 주입된 EntityManager 가 프록시임을 증명하기
    //
    // 요구사항:
    //   (1) em.getClass().getName() 을 출력하세요.
    //   (2) (em instanceof EntityManager) 를 출력하세요.
    //   (3) 두 출력이 동시에 성립한다는 것이 무슨 뜻인지 한 줄로 적으세요.
    //       답:
    //   (4) 이 사실이 왜 싱글턴 JPAQueryFactory 를 안전하게 만드는지 한 줄로 적으세요.
    //       답:
    // =====================================================================
    @Test
    @DisplayName("문제 3. EntityManager 프록시 증명")
    void 문제3_EntityManager_프록시() {
        // 여기에 작성:

    }

    // =====================================================================
    // 문제 4. GOLD 등급 + 포인트 3000 이상 고객 조회
    //
    // 요구사항:
    //   - selectFrom 을 사용할 것
    //   - 조건 두 개를 and 로 묶을 것
    //   - 결과를 이름과 포인트로 출력할 것
    //   - 콘솔의 hibernate.SQL 로그에서 생성 SQL 을 확인할 것
    //
    // 기대 결과: 6건
    // 기대 SQL:
    //   select c1_0.customer_id, c1_0.city, ... from customers c1_0
    //   where c1_0.grade = ? and c1_0.points >= ?
    // =====================================================================
    @Test
    @DisplayName("문제 4. GOLD 등급 + 포인트 3000 이상")
    void 문제4_GOLD_포인트조회() {
        // 여기에 작성:
        List<Customer> result = null;

        // result.forEach(c -> System.out.println(c.getName() + " " + c.getPoints()));
    }

    // =====================================================================
    // 문제 5. JPQL 과 SQL 을 나란히 출력하고 차이를 서술하기  ★ 이 문제지에서 가장 중요
    //
    // 요구사항:
    //   (1) VIP 이면서 도시가 "서울"인 고객을 조회하는 JPAQuery 를 만들되,
    //       바로 fetch() 하지 말고 변수에 담으세요.
    //   (2) query.toString() 으로 JPQL 을 먼저 출력하세요.
    //   (3) 그다음 fetch() 를 호출해 hibernate.SQL 로그를 띄우세요.
    //   (4) 두 출력의 차이를 3가지 적으세요.
    //       차이 1:
    //       차이 2:
    //       차이 3:
    // =====================================================================
    @Test
    @DisplayName("문제 5. JPQL vs SQL 차이 3가지")
    void 문제5_JPQL과_SQL의_차이() {
        // 여기에 작성:
        JPAQuery<Customer> query = null;

        // System.out.println(query.toString());
        // query.fetch();
    }

    // =====================================================================
    // 문제 6. fetchOne 의 NonUniqueResultException 재현과 대안
    //
    // 요구사항:
    //   (1) fetchOne() 이 NonUniqueResultException 을 던지는 조건을 만들어
    //       실제로 예외가 나는 것을 확인하고 메시지를 출력하세요.
    //       (힌트: 결과가 2건 이상 나오는 조건이면 됩니다)
    //   (2) 같은 의도를 안전하게 처리하는 방법 두 가지로 고쳐 쓰세요.
    //       대안 A:
    //       대안 B:
    //   (3) 두 대안 중 어느 쪽도 해결해 주지 못하는 것이 무엇인지 한 줄로 적으세요.
    //       답:
    // =====================================================================
    @Test
    @DisplayName("문제 6. fetchOne 예외 재현과 대안")
    void 문제6_fetchOne_예외와_대안() {
        // (1) 예외 재현 — 여기에 작성:

        // (2) 대안 A — 여기에 작성:

        // (2) 대안 B — 여기에 작성:

    }
}

package com.example.shop.step01;

import com.example.shop.entity.Customer;
import com.example.shop.entity.Grade;
import com.querydsl.core.NonUniqueResultException;
import com.querydsl.jpa.impl.JPAQuery;
import com.querydsl.jpa.impl.JPAQueryFactory;
import jakarta.persistence.EntityManager;
import jakarta.persistence.PersistenceContext;
import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.transaction.annotation.Transactional;

import java.util.List;

import static com.example.shop.entity.QCustomer.customer;
import static org.assertj.core.api.Assertions.assertThat;
import static org.assertj.core.api.Assertions.assertThatThrownBy;

/**
 * Step 01 — 연습문제 정답과 해설
 *
 * 문제를 직접 풀어 본 뒤에 여세요.
 *
 * 실행:
 *   ./gradlew test --tests 'com.example.shop.step01.Solution'
 */
@SpringBootTest
@Transactional
class Solution {

    @Autowired
    JPAQueryFactory queryFactory;

    @PersistenceContext
    EntityManager em;

    // =====================================================================
    // 정답 1. 오타의 발견 시점 비교
    //
    // 【핵심】 키워드 오타와 필드명 오타는 "다른 예외"가 납니다.
    //
    //   selct  (키워드 오타)  → org.hibernate.query.SyntaxException
    //   c.grde (필드명 오타)  → org.hibernate.query.SemanticException
    //
    // 왜 다른가?
    //   Hibernate 6 의 HQL 처리는 두 단계입니다.
    //     ① 파싱(syntax)   : 토큰이 문법에 맞는가. 'selct' 는 아예 키워드가 아니므로 여기서 실패.
    //     ② 의미 해석(semantic) : 파싱은 통과했지만 Customer 에 grde 라는 속성이 없으므로 여기서 실패.
    //   즉 필드명 오타는 "문법적으로는 올바른 문장"입니다. 그래서 파서를 통과합니다.
    //
    // Hibernate 5 를 쓰던 자료에서는 둘 다 QuerySyntaxException 이었습니다.
    // Hibernate 6 에서 ANTLR 기반으로 파서를 새로 쓰면서 예외 계층이 분화됐습니다.
    // 인터넷 검색으로 QuerySyntaxException 이 안 잡힌다면 이 때문입니다.
    //
    // (3) 발견 시점의 차이 — 이 문제의 진짜 답:
    //   문자열 JPQL 의 오타는 "그 코드 경로를 실행할 때" 발견됩니다.
    //   즉 테스트가 그 경로를 안 밟으면 배포까지 살아남고, 최초 사용자가 대신 발견합니다.
    //   QueryDSL 은 ./gradlew compileJava 단계에서 발견됩니다.
    //   실행 여부와 무관하게, 커버리지와 무관하게, 100% 발견됩니다.
    //   이 "100%" 가 QueryDSL 을 쓰는 이유의 전부입니다.
    // =====================================================================
    @Test
    @DisplayName("정답 1. 오타의 발견 시점 비교")
    void 정답1_오타의_발견시점() {
        String jpql = "select c from Customer c where c.grde = :grade";

        assertThatThrownBy(() ->
                em.createQuery(jpql, Customer.class)
                        .setParameter("grade", Grade.VIP)
                        .getResultList()
        ).satisfies(e -> {
            System.out.println("예외 클래스 : " + e.getClass().getName());
            System.out.println("메시지     : " + e.getMessage());
        });

        // QueryDSL 판 — 아래 주석을 풀면 컴파일이 실패합니다.
        //   queryFactory.selectFrom(customer).where(customer.grde.eq(Grade.VIP)).fetch();
        //   error: cannot find symbol
        //     symbol: variable grde, location: variable customer of type QCustomer
    }

    // =====================================================================
    // 정답 2. build.gradle 판정
    //
    // (a) querydsl-jpa:6.12:jakarta  →  (A) 빌드 실패
    //     6.x 는 Jakarta 를 네이티브로 삼았기 때문에 jakarta classifier 아티팩트를
    //     아예 발행하지 않습니다. Maven Central 에 그런 파일이 없습니다.
    //       Could not find querydsl-jpa-6.12-jakarta.jar
    //     5.x 습관을 그대로 옮겼을 때 나오는 가장 흔한 케이스이고,
    //     그나마 증상이 명확해서 다행인 케이스입니다.
    //
    // (b) querydsl-apt:6.12 (classifier 누락)  →  (B) 빌드 성공하지만 Q타입 미생성
    //     ★ 이 문항이 가장 많이 틀립니다. "빌드 실패"로 답하기 쉽습니다.
    //     querydsl-apt:6.12 는 실제로 존재하는 아티팩트라 의존성 해결이 성공합니다.
    //     하지만 그 기본 아티팩트에는 JPA 프로세서를 등록하는
    //     META-INF/services/javax.annotation.processing.Processor 항목이 없습니다.
    //     → APT 가 조용히 아무 일도 하지 않고, BUILD SUCCESSFUL 이 뜹니다.
    //     → 그다음 Q타입을 참조하는 코드에서 cannot find symbol 이 납니다.
    //     확인 명령: find build/generated -name 'Q*.java'  (출력이 없으면 이 케이스)
    //
    // (c) querydsl-jpa:5.0.0 (classifier 없음)  →  (C) 런타임 실패
    //     ★ 네 개 중 가장 위험합니다. 빌드가 초록불이기 때문입니다.
    //     5.0.0 기본 아티팩트는 javax.persistence 를 참조하는데,
    //     Spring Boot 3 / Jakarta EE 9+ 환경에는 그 패키지 자체가 없습니다.
    //       java.lang.NoClassDefFoundError: javax/persistence/Entity
    //     첫 쿼리를 실행하는 순간, 즉 서버가 뜬 뒤에 터집니다.
    //
    // (d) 정답 조합  →  (D) 정상
    //     jpa 는 classifier 없음, apt 만 :jpa.
    //     jakarta.persistence-api / jakarta.annotation-api 를 annotationProcessor 에
    //     추가한 것도 필수입니다. 프로세서가 엔티티를 읽을 때 이 API 가 프로세서
    //     클래스패스에 있어야 하기 때문입니다. 빠지면 Q타입이 부분적으로만 생성되거나
    //     cannot access jakarta.persistence.Entity 가 납니다.
    //
    // 【외울 것 한 줄】
    //   6.x → jpa 는 classifier 없음, apt 만 :jpa
    //   5.x → 양쪽 다 :jakarta
    //   두 classifier 의 "축"이 다르기 때문입니다.
    //     jpa 의 축 = javax냐 jakarta냐  (6.x 는 jakarta 하나뿐 → 축이 소멸)
    //     apt 의 축 = 어느 프로세서냐    (6.x 도 여전히 여러 개 → 축이 유지)
    // =====================================================================
    @Test
    @DisplayName("정답 2. build.gradle 판정")
    void 정답2_의존성_판정() {
        System.out.println("(a) A 빌드실패 / (b) B Q타입미생성 / (c) C 런타임실패 / (d) D 정상");
    }

    // =====================================================================
    // 정답 3. EntityManager 프록시 증명
    //
    // 출력 예:
    //   클래스명       : jdk.proxy2.$Proxy214
    //   인터페이스 만족 : true
    //
    // (3) 두 출력이 동시에 성립한다는 뜻:
    //   "EntityManager 인터페이스를 구현한 동적 프록시"라는 뜻입니다.
    //   타입은 EntityManager 가 맞지만, 실제 구현체(SessionImpl)는 아닙니다.
    //   호출을 받아 다른 객체에게 넘기는 중간자입니다.
    //
    //   이 프록시를 만드는 것은 스프링의 SharedEntityManagerCreator 이고,
    //   호출을 가로채는 것은 SharedEntityManagerInvocationHandler 입니다.
    //   핸들러가 하는 일은 매 호출마다 이것뿐입니다:
    //     "TransactionSynchronizationManager 에서 지금 이 스레드에 바인딩된
    //      EntityManager 를 꺼내서, 거기로 위임한다."
    //
    // (4) 왜 싱글턴 JPAQueryFactory 가 안전한가:
    //   JPAQueryFactory 가 붙들고 있는 것은 "특정 영속성 컨텍스트"가 아니라
    //   "지금 스레드의 영속성 컨텍스트를 찾아 주는 함수"이기 때문입니다.
    //   스레드 A 의 호출은 A 의 세션으로, 스레드 B 의 호출은 B 의 세션으로 갑니다.
    //   공유되는 상태가 없으므로 싱글턴으로 두어도 됩니다.
    //
    //   ★ 반대로 emf.createEntityManager() 로 만든 진짜 EntityManager 를
    //     싱글턴에 고정하면 이 분리가 사라집니다. 모든 스레드가 하나의 세션을 공유하고,
    //     ConcurrentModificationException / "Session is closed" 가 산발적으로 납니다.
    //     그리고 이 버그는 단일 스레드로 도는 테스트로는 절대 잡히지 않습니다.
    //     테스트로 못 잡는 버그이므로 "규칙"으로 막아야 합니다:
    //     애플리케이션 코드에서 emf.createEntityManager() 를 직접 호출하지 말 것.
    // =====================================================================
    @Test
    @DisplayName("정답 3. EntityManager 프록시 증명")
    void 정답3_EntityManager_프록시() {
        System.out.println("클래스명       : " + em.getClass().getName());
        System.out.println("인터페이스 만족 : " + (em instanceof EntityManager));

        assertThat(em.getClass().getName()).contains("Proxy");
        assertThat(em).isInstanceOf(EntityManager.class);

        // 프록시 뒤의 실제 세션 (확인용. 애플리케이션 코드에서 이러지 마세요)
        System.out.println("실제 세션      : "
                + em.unwrap(org.hibernate.Session.class).getClass().getName());
    }

    // =====================================================================
    // 정답 4. GOLD 등급 + 포인트 3000 이상
    //
    // 조건을 and 로 묶는 방법은 두 가지이고 결과 SQL 은 동일합니다.
    //   ① .where(A.and(B))
    //   ② .where(A, B)          ← 쉼표로 나열하면 QueryDSL 이 and 로 묶습니다
    //
    // ②를 권장합니다. 이유는 Step 04 에서 본격적으로 다루지만 미리 말하면,
    // 쉼표 나열은 인자 중 null 을 "조건 없음"으로 무시하기 때문에
    // 동적 쿼리를 조립할 때 그대로 재사용할 수 있습니다.
    //   .where(gradeEq(cond), pointsGoe(cond))   // null 이면 그 조건만 빠짐
    // .and() 체이닝은 앞이 null 이면 NullPointerException 이 납니다.
    //
    // 생성 SQL:
    //   select c1_0.customer_id, c1_0.city, c1_0.created_at, c1_0.email,
    //          c1_0.grade, c1_0.name, c1_0.phone, c1_0.points
    //   from customers c1_0
    //   where c1_0.grade = ? and c1_0.points >= ?
    //   바인딩: [1] GOLD, [2] 3000  → 6건
    //
    // 여기서 확인할 것: 값이 SQL 문자열에 박히지 않고 ? 로 나갔다는 것입니다.
    // QueryDSL 은 상수를 자동으로 바인딩 파라미터로 만듭니다.
    // 문자열을 이어붙이는 코드가 없으므로 SQL 인젝션이 구조적으로 불가능하고,
    // DB 가 실행계획을 재사용할 수 있습니다.
    // =====================================================================
    @Test
    @DisplayName("정답 4. GOLD 등급 + 포인트 3000 이상")
    void 정답4_GOLD_포인트조회() {
        List<Customer> result = queryFactory
                .selectFrom(customer)
                .where(
                        customer.grade.eq(Grade.GOLD),
                        customer.points.goe(3000)
                )
                .fetch();

        result.forEach(c -> System.out.println(c.getName() + " " + c.getPoints()));
        assertThat(result).hasSize(6);
    }

    // =====================================================================
    // 정답 5. JPQL vs SQL 차이 3가지   ★ 이 스텝의 핵심
    //
    // toString() 출력 (JPQL):
    //   select customer
    //   from Customer customer
    //   where customer.grade = ?1 and customer.city = ?2
    //
    // hibernate.SQL 출력 (SQL):
    //   select c1_0.customer_id, c1_0.city, c1_0.created_at, c1_0.email,
    //          c1_0.grade, c1_0.name, c1_0.phone, c1_0.points
    //   from customers c1_0
    //   where c1_0.grade = ? and c1_0.city = ?
    //
    // 차이 1 — 별칭
    //   JPQL: customer  (우리가 static import 한 Q타입의 변수명이 그대로 별칭이 됩니다)
    //   SQL : c1_0      (Hibernate 6 이 <엔티티 첫 글자><인덱스>_<서브인덱스> 로 만듭니다)
    //   Hibernate 5 는 customer0_ 형태였습니다. 별칭 모양만 봐도 세대를 구별할 수 있습니다.
    //
    // 차이 2 — from 대상
    //   JPQL: Customer   (자바 클래스 이름)
    //   SQL : customers  (DB 테이블 이름)
    //   ★ QueryDSL 은 "customers" 라는 문자열을 단 한 번도 만들지 않습니다.
    //     테이블 이름을 아는 것은 Hibernate 이고, 매핑(@Table)에서 가져옵니다.
    //
    // 차이 3 — 파라미터 표기
    //   JPQL: ?1, ?2  (번호가 붙은 위치 파라미터)
    //   SQL : ?, ?    (JDBC 자리표시자, 번호 없음)
    //   주의: JPQL 의 ?1 이 SQL 의 첫 번째 ? 와 항상 일치한다고 가정하면 안 됩니다.
    //   in 절 확장이나 상속 판별 조건이 추가되면 SQL 쪽 ? 가 더 많아집니다.
    //   실제 바인딩 값은 org.hibernate.orm.jdbc.bind 로그로 확인하세요.
    //
    // 차이 4 (보너스) — 조회 대상의 세밀도
    //   JPQL: select customer   → "이 엔티티를 통째로"
    //   SQL : 8개 컬럼을 전부 나열
    //   엔티티를 조회하면 항상 모든 컬럼이 나갑니다. 필요한 두 컬럼만 읽고 싶다면
    //   프로젝션을 써야 하며, 그것이 Step 05 의 주제입니다.
    //
    // 【이 절이 왜 중요한가】
    //   QueryDSL 의 출력물은 JPQL 까지입니다. SQL 은 Hibernate 의 결과물입니다.
    //   따라서 JPQL 이 못 하는 것은 QueryDSL 도 못 합니다.
    //     - from 절 서브쿼리(인라인 뷰)  → 불가
    //     - UNION                        → 불가
    //     - 윈도우 함수                  → 불가 (JPA 모듈에서는)
    //   Step 07 에서 이 벽에 부딪히는데, 그때 "왜 안 되는가"의 답이 여기입니다.
    //
    // 【디버깅 요령】
    //   의도와 다른 SQL 이 나갈 때는 SQL 로그부터 보지 말고 toString() 부터 보세요.
    //     JPQL 이 이미 이상하다  → 내 QueryDSL 코드가 틀렸다
    //     JPQL 은 맞는데 SQL 이 이상하다 → 엔티티 매핑/페치 전략 문제다
    //   이 두 갈래로 나누는 것만으로 디버깅 시간이 절반이 됩니다.
    //   toString() 은 쿼리를 실행하지 않으므로 마음껏 찍어도 됩니다.
    // =====================================================================
    @Test
    @DisplayName("정답 5. JPQL vs SQL 차이 3가지")
    void 정답5_JPQL과_SQL의_차이() {
        JPAQuery<Customer> query = queryFactory
                .selectFrom(customer)
                .where(
                        customer.grade.eq(Grade.VIP),
                        customer.city.eq("서울")
                );

        System.out.println("===== JPQL (실행 전) =====");
        System.out.println(query.toString());

        System.out.println("===== SQL (아래 hibernate.SQL 로그) =====");
        List<Customer> result = query.fetch();

        result.forEach(c -> System.out.println(c.getName()));
        assertThat(result).hasSize(2);      // 김서준, 정  훈
    }

    // =====================================================================
    // 정답 6. fetchOne 예외 재현과 대안
    //
    // (1) 재현
    //   city = "서울" 인 고객은 9명이므로 fetchOne() 은 반드시 터집니다.
    //     com.querydsl.core.NonUniqueResultException:
    //       Only one result is allowed for fetchOne calls
    //
    //   ★ 주의: QueryDSL 은 이 예외를 "결과를 다 가져온 뒤"에 던집니다.
    //     즉 9건을 DB 에서 전부 읽어 온 다음에 예외가 납니다.
    //     조건이 잘못돼서 100만 건이 매칭되면 100만 건을 읽고 나서 터집니다.
    //     예외가 났다고 해서 쿼리가 가벼웠던 게 아닙니다.
    //
    // (2) 대안 A — fetchFirst()
    //   내부적으로 limit(1) 을 붙입니다. 생성 SQL 끝에 limit ? 가 붙으므로
    //   DB 가 1건만 반환합니다. 위의 "다 읽고 터진다" 문제도 없습니다.
    //   단, 정렬이 없으면 "어느 1건"인지 DB 마음입니다.
    //   반드시 orderBy 를 함께 주세요. 이게 안 되어 있으면
    //   개발 DB 와 운영 DB 에서 다른 행이 나오는 현상이 생깁니다.
    //
    // (2) 대안 B — fetch() 후 size() 검사
    //   건수를 코드가 알고 있으므로 예외 대신 분기로 처리할 수 있습니다.
    //   "0건이면 기본값, 1건이면 그것, 2건 이상이면 로그를 남기고 첫 건" 같은
    //   비즈니스 규칙을 표현할 수 있습니다.
    //   단점은 전부 읽어 온다는 것이라, 결과가 많을 수 있으면 limit 을 함께 거세요.
    //
    // (3) 어느 쪽도 해결해 주지 못하는 것:
    //   ★ "이 조건이 정말 유일한가"는 코드가 판단해 주지 않습니다.
    //   fetchFirst() 로 바꾸면 예외는 사라지지만, 사실 2건이 나와야 정상인
    //   상황에서 조용히 1건만 쓰게 됩니다 — 에러 없이 틀린 결과를 반환하는 것이라
    //   예외가 나는 것보다 더 나쁠 수 있습니다.
    //   유일성이 보장되는 것은 DB 의 UNIQUE 제약뿐입니다.
    //   customers 테이블에는 uk_customers_email 이 있으므로 email 조회는 안전하고,
    //   city 나 name 은 제약이 없으므로 언제든 2건이 될 수 있습니다.
    //   fetchOne() 을 쓸지 말지의 기준은 "지금 데이터가 1건인가"가 아니라
    //   "스키마가 1건을 보장하는가" 입니다.
    // =====================================================================
    @Test
    @DisplayName("정답 6. fetchOne 예외 재현과 대안")
    void 정답6_fetchOne_예외와_대안() {
        // (1) 재현
        assertThatThrownBy(() ->
                queryFactory.selectFrom(customer)
                        .where(customer.city.eq("서울"))
                        .fetchOne()
        ).isInstanceOf(NonUniqueResultException.class)
         .satisfies(e -> System.out.println("예외 : " + e.getMessage()));

        // (2) 대안 A — fetchFirst + orderBy (정렬 없이 쓰지 말 것)
        Customer first = queryFactory.selectFrom(customer)
                .where(customer.city.eq("서울"))
                .orderBy(customer.id.asc())
                .fetchFirst();
        System.out.println("대안 A 첫 건 : " + first.getName());

        // (2) 대안 B — fetch 후 건수로 분기
        List<Customer> found = queryFactory.selectFrom(customer)
                .where(customer.city.eq("서울"))
                .fetch();
        System.out.println("대안 B 건수 : " + found.size());
        if (found.size() == 1) {
            System.out.println("단건 : " + found.get(0).getName());
        } else {
            System.out.println("단건이 아님 → 비즈니스 규칙으로 처리");
        }

        // (참고) 스키마가 유일성을 보장하는 조회 — email 은 UNIQUE 제약이 있습니다
        Customer byEmail = queryFactory.selectFrom(customer)
                .where(customer.email.eq("seojun.kim@example.com"))
                .fetchOne();
        System.out.println("email 단건 : " + (byEmail == null ? "null" : byEmail.getName()));
    }
}