Part of your World

#### 발생 원인:

- **타입 불일치**: 쿼리 결과에서 `employeesName` 컬럼은 문자열 타입인데, 해당 컬럼을 `int`로 처리하려고 시도하여 `SQLException`이 발생.
    - **에러 메시지**:

1. ResultSet.getInt(employeesName) java.sql.SQLException: Out of range value for column 'employeesName': value 박현아

    - **문제**: `employeesName` 컬럼의 값이 실제로는 문자열(`"박현아"`)인데, 이를 `int`로 변환하려고 시도했기 때문에 타입 불일치 오류가 발생.

#### 영향 범위:

- **데이터 매핑 오류**: `employeesName` 값을 `int`로 처리하려고 시도했기 때문에 데이터 매핑이 올바르게 처리되지 않음. 이는 `employeesName`을 사용하는 모든 로직에서 오류를 발생시킴.
- **응답 실패**: 쿼리 결과를 처리하는 과정에서 `SQLException`이 발생하여 애플리케이션이 예상대로 동작하지 않음.
- **타입 불일치**: 데이터베이스 컬럼의 타입과 Java 모델 객체의 타입이 일치하지 않아서, 데이터를 가져오는 과정에서 오류가 발생.

#### 주요 프로세스 영향:

1. **데이터 조회 실패**:
    - `ResultSet.getInt()` 메소드에서 `employeesName` 값을 `int`로 읽으려 했지만, 컬럼이 문자열이므로 `SQLException`이 발생. 이로 인해 데이터 조회가 실패함.
2. **잘못된 모델 매핑**:
    - 모델 객체에서 `employeesName` 필드를 `int`로 선언한 경우, 데이터베이스에서 문자열 값을 올바르게 매핑할 수 없어서 오류가 발생.
3. **응답 지연**:
    - 쿼리 실행 중 오류가 발생하여 응답을 제대로 반환할 수 없게 되고, 클라이언트에 오류 응답이 전송됨.

#### 해결 방안:

1. **모델 수정**:
    
    - `employeesName` 컬럼의 값을 올바르게 처리할 수 있도록 모델 객체에서 `employeesName` 필드를 `String` 타입으로 변경.
    - **수정된 코드**:

private String employeesName;  // String 타입으로 수정

2. **타입 일치 검토**:
    
    - 데이터베이스 컬럼 타입과 Java 모델 타입이 일치하는지 항상 확인해야 하며, 쿼리 결과를 매핑할 때 타입 불일치가 발생하지 않도록 유의.
    - 문자열 값을 `int`로 변환하려고 할 경우, 해당 컬럼이 실제로 숫자 값임을 확인한 후 변환해야 합니다.
3. **테스트 및 검증**:
    
    - 모델 타입을 변경한 후, 데이터베이스에서 쿼리를 실행하고 모델 객체에 데이터를 제대로 매핑할 수 있는지 테스트.
    - 다양한 문자열 데이터를 테스트하여 오류가 발생하지 않는지 확인.
4. **로깅 및 예외 처리**:
    
    - `SQLException`이 발생할 가능성이 있는 경우, 적절한 예외 처리와 로깅을 추가하여 문제 발생 시 빠르게 원인을 추적할 수 있도록 함.
    - 예를 들어, `SQLException`을 잡아서 상세한 오류 메시지를 로깅할 수 있습니다.
5. **쿼리 최적화**:
    
    - 쿼리에서 필요한 컬럼만 선택적으로 조회하거나, 데이터 타입에 맞는 필드를 사용하여 쿼리 성능을 최적화할 수 있습니다.

#### 결론:

`employeesName` 컬럼의 값을 `int` 타입으로 처리하려고 시도하여 발생한 `SQLException`을 해결하기 위해, Java 모델 객체에서 `employeesName` 필드를 `String` 타입으로 변경해야 합니다. 이를 통해 데이터베이스에서 반환되는 문자열 값을 올바르게 처리할 수 있습니다. 타입 일치를 확인하고, 예외 처리를 적절히 적용하여 데이터 조회 오류를 예방해야 합니다.

### 에러 노트: NullPointerException - 포인트 값이 없을 경우

#### 발생 원인:

- **`NullPointerException` 발생**: `MobilePoint` 객체가 `null`일 경우, `point.getPoint()` 메소드 호출에서 `NullPointerException`이 발생.
    - **기존 코드**:

        return new PageImpl<>(list.getResults().stream()       
        .map(tuple -> {           
        MobileUsers data = tuple.get(userInfo);           
        MobilePoint point = tuple.get(userPoint);           
        return new MobileUserDTO.UserListData(               
        point.getPoint()          
        );       
        })       
        .collect(Collectors.toList()), pageable, list.getTotal());

        
    - **문제**: `point`가 `null`일 때 `point.getPoint()`를 호출하려고 해서 `NullPointerException`이 발생.
    - **해결 코드**:

        return new PageImpl<>(list.getResults().stream()       
            .map(tuple -> {           
            MobileUsers data = tuple.get(userInfo);           
        MobilePoint point = tuple.get(userPoint);           
        return new MobileUserDTO.UserListData(               
        point != null && point.getPoint() != null ? point.getPoint() : 0               
        // point가 null일 경우 0 반환           
        );       
        })       
        .collect(Collectors.toList()), pageable, list.getTotal());

#### 영향 범위:

- **NullPointerException**: `MobilePoint` 객체가 `null`일 경우, `point.getPoint()` 호출 시 예외가 발생하여 애플리케이션이 중단될 수 있음.
- **데이터 처리 오류**: `point`가 `null`인 경우에도 `getPoint()`를 안전하게 처리하지 않으면, 해당 사용자에 대한 데이터를 처리할 수 없거나, 오류가 발생하여 결과가 정상적으로 반환되지 않음.

#### 주요 프로세스 영향:

1. **데이터 조회 실패**:
    - `MobilePoint` 객체가 `null`인 경우, `point.getPoint()` 호출에서 오류가 발생하여, 해당 사용자의 정보가 잘못 처리되거나 조회되지 않음.
2. **응답 지연**:
    - 예외가 발생하여 요청이 실패하거나 예외 처리 로직으로 넘어가게 되어, 응답 시간이 지연될 수 있음.
3. **서비스 장애**:
    - `NullPointerException`으로 인해 서비스가 중단되거나, 일부 기능이 정상적으로 작동하지 않음.

#### 해결 방안:

1. **`null` 체크 추가**:
    
    - `MobilePoint` 객체가 `null`일 경우, `getPoint()`를 호출하지 않도록 `null` 체크를 추가하여 `NullPointerException`을 방지.
    - `point`가 `null`일 경우에는 기본 값(예: `0`)을 반환하도록 처리.
    - **수정된 코드**:

return new PageImpl<>(list.getResults().stream()       
  .map(tuple -> {           
  MobileUsers data = tuple.get(userInfo);           
  MobilePoint point = tuple.get(userPoint);           
return new MobileUserDTO.UserListData(               
point != null && point.getPoint() != null ? point.getPoint() : 0               
// point가 null일 경우 0 반환           
);       
})       
.collect(Collectors.toList()), pageable, list.getTotal());

        
2. **`Optional` 사용**:
    
    - `Optional`을 사용하여 `null` 처리를 더 안전하게 할 수 있음. 예를 들어, `point.getPoint()` 대신 `Optional.ofNullable(point).map(MobilePoint::getPoint).orElse(0)`와 같이 처리할 수 있음.
       

   return new PageImpl<>(list.getResults().stream()       
   .map(tuple -> {           
   MobileUsers data = tuple.get(userInfo);           
   MobilePoint point = tuple.get(userPoint);           
   return new MobileUserDTO.UserListData(               
   Optional.ofNullable(point).map(MobilePoint::getPoint).orElse(0)           
   );       
   })       
   .collect(Collectors.toList()), pageable, list.getTotal());

        
3. **테스트 및 검증**:
    
    - 수정된 코드가 정상적으로 동작하는지 확인하기 위해, `point`가 `null`인 경우와 아닌 경우에 대해 다양한 테스트를 진행.
    - 특히 `point`가 `null`일 때 결과가 `0`으로 반환되는지 검증.
4. **로깅**:
    
    - `point`가 `null`인 경우에 대한 로깅을 추가하여, 데이터가 `null`인 이유와 함께 문제를 추적할 수 있도록 함.
    - 예시:

if (point == null) {     
log.warn("MobilePoint is null for user: {}",data.getId()); 
}

#### 결론:

`MobilePoint` 객체가 `null`일 경우 `getPoint()` 메소드 호출에서 `NullPointerException`이 발생하는 문제를 해결하기 위해 `null` 체크를 추가하여 안전하게 처리하도록 수정해야 합니다. `Optional`을 사용하면 코드가 더 깔끔하고 안전하게 `null` 값을 처리할 수 있습니다. 이를 통해 애플리케이션이 중단되지 않고 정상적으로 데이터를 처리할 수 있습니다.

#### 발생 원인:

- **`unexpected token: with` 오류**: JPA 쿼리에서 `with` 구문을 잘못 사용하거나, 쿼리의 구조가 잘못되어 Hibernate가 쿼리를 올바르게 해석하지 못함. 오류 메시지에서 `unexpected token: with`가 나타나며, 이는 쿼리에서 잘못된 구문이 사용되었음을 나타냄.
    - **기존 코드**:

JPAQuery<Tuple> jpaQuery = queryFactory       
.select(userInfo, userPoint.point)       
.join(userPoint).on(userInfo.tokenId.eq(userPoint.tokenId))     
.from(userInfo);

        
    - **문제**: `from` 절이 잘못 배치되어 `join` 구문이 `with` 구문처럼 해석되는 문제가 발생. 이로 인해 Hibernate가 예상하지 못한 `with` 토큰을 만남.

    - **해결 코드**:

JPAQuery<Tuple> jpaQuery = queryFactory       
.select(userInfo, userPoint.point)       
.from(userInfo)       
.join(userPoint).on(userInfo.tokenId.eq(userPoint.tokenId));

        
    - **수정**: `from` 절을 쿼리의 처음에 배치하여 `join` 구문이 올바르게 해석되도록 수정.

#### 영향 범위:

- **쿼리 실행 오류**: `from`과 `join` 구문이 잘못 배치되어 쿼리가 Hibernate에서 실행되지 않음. 이로 인해 데이터 조회가 실패하고 애플리케이션에서 오류가 발생.
- **잘못된 쿼리 생성**: QueryDSL에서 쿼리의 구조가 잘못 설정되어, Hibernate가 쿼리를 올바르게 해석하지 못하고 `QuerySyntaxException`이 발생.

#### 주요 프로세스 영향:

1. **데이터 조회 실패**:
    - 잘못된 쿼리 구조로 인해 쿼리가 실행되지 않거나, SQL 구문 오류가 발생하여 결과가 반환되지 않음.
2. **서비스 오류**:
    - 쿼리 오류로 인해 해당 API 호출이 실패하고, 응답이 제대로 반환되지 않음.
3. **디버깅 어려움**:
    - Hibernate의 쿼리 해석 오류가 발생하면서 문제의 원인을 추적하기 어려울 수 있음.

#### 해결 방안:

1. **`from` 절의 위치 수정**:
    
    - `join` 구문을 사용할 때, `from` 절은 쿼리에서 먼저 선언되어야 하며, 그 후에 `join` 절을 추가해야 합니다.

    - **수정된 코드**:

JPAQuery<Tuple> jpaQuery = queryFactory       
.select(userInfo, userPoint.point)       
.from(userInfo)       
.join(userPoint).on(userInfo.tokenId.eq(userPoint.tokenId));

        
2. **QueryDSL 구문 체크**:
    
    - QueryDSL에서 쿼리를 작성할 때는 `from` 절이 항상 먼저 나오고, 그 후에 `join` 및 기타 절들이 나와야 한다는 점을 확인.
    - `select`와 `from` 구문을 올바르게 구성하여 쿼리의 실행 흐름을 맞춰야 합니다.
3. **쿼리 문법 검토**:
    
    - `select`와 `from` 절, `join` 구문을 사용하는 올바른 순서를 확인하고, Hibernate나 JPA에서 요구하는 쿼리 문법에 맞게 작성.
    - `with` 구문은 JPA에서 지원하지 않으므로, 쿼리 구조가 `with`를 포함하지 않도록 주의.
4. **쿼리 실행 전 테스트**:
    
    - 수정된 쿼리를 실행하기 전에 단위 테스트나 통합 테스트에서 쿼리가 정상적으로 실행되는지 검증.
    - 쿼리 로그를 활성화하여 실제 SQL 쿼리가 어떻게 변환되는지 확인하고, 오류가 없는지 점검.
5. **로깅 및 예외 처리**:
    
    - 쿼리 실행 시 오류가 발생할 경우, 자세한 로깅을 통해 문제를 추적하고, 문제 해결 후 정상적으로 데이터가 반환되는지 확인.

### 에러 노트: SQL 조인 위치 실수

#### 발생 원인:

- **조인 순서 실수**: `h_charge_complete` 테이블과 `h_certify` 테이블을 조인하는 순서가 잘못 설정되어 `Unknown column 'h_certify.return_certkey' in 'on clause'` 오류가 발생.
    - **잘못된 쿼리**:
        
        sql

SELECT 
protocol_charge_operation_list.sid 
FROM protocol_charge_operation_list 
LEFT JOIN h_charge_complete ON h_charge_complete.certify_key = h_certify.return_certkey 
LEFT JOIN h_certify ON h_certify.cert_operator_by = protocol_charge_operation_list.code

        
    - **문제**: `h_charge_complete` 테이블에서 `h_certify.return_certkey`를 참조하는데, 이때 `h_certify` 테이블이 `h_charge_complete`와 조인되기 전에 사용되고 있어서 `h_certify` 테이블의 `return_certkey` 컬럼을 찾을 수 없는 오류 발생.
    - **해결된 쿼리**:
        
        sql

SELECT protocol_charge_operation_list.sid 
FROM protocol_charge_operation_list 
LEFT JOIN h_certify ON h_certify.cert_operator_by = protocol_charge_operation_list.code 
LEFT JOIN h_charge_complete ON h_charge_complete.certify_key = h_certify.return_certkey

        
    - **문제 해결**: `h_certify` 테이블을 먼저 조인한 후, 그 결과를 사용하여 `h_charge_complete`와 올바르게 조인함.

#### 영향 범위:

- 이 오류는 `h_charge_complete`와 `h_certify` 테이블 간의 조인 순서를 잘못 설정할 경우 발생.
- `h_certify.return_certkey`를 참조하는 쿼리에서 올바른 순서로 테이블을 조인하지 않으면, SQL 실행 시 컬럼을 찾을 수 없다는 오류가 발생.

#### 주요 프로세스 영향:

1. **조인 관계 불일치**:
    - `h_charge_complete` 테이블과 `h_certify` 테이블이 올바르게 조인되지 않아서, `h_certify.return_certkey` 컬럼을 찾을 수 없는 문제가 발생.
2. **쿼리 실행 실패**:
    - SQL 쿼리가 실행되지 않거나, 결과가 반환되지 않음. 이로 인해, 데이터가 조회되지 않거나 예상된 결과를 얻을 수 없음.
3. **조인 오류로 인한 데이터 불일치**:
    - 잘못된 조인 순서로 인해 데이터가 잘못 결합되거나 누락될 수 있음.

#### 해결 방안:

1. **조인 순서 수정**:
    
    - `h_certify` 테이블을 먼저 조인하고, 그 후에 `h_charge_complete` 테이블을 조인하여 `h_certify.return_certkey` 컬럼을 정상적으로 참조할 수 있도록 해야 함.
    - SQL 쿼리에서 `LEFT JOIN` 순서를 올바르게 변경:
        
        sql

SELECT protocol_charge_operation_list.sid 
FROM protocol_charge_operation_list 
LEFT JOIN h_certify ON h_certify.cert_operator_by = protocol_charge_operation_list.code 
LEFT JOIN h_charge_complete ON h_charge_complete.certify_key = h_certify.return_certkey

        
2. **쿼리 검증**:
    
    - 수정된 쿼리가 정상적으로 실행되는지, `h_certify`와 `h_charge_complete` 간의 관계가 올바르게 설정되었는지 확인.
    - 필요에 따라, `h_certify` 테이블에서 `return_certkey` 컬럼이 정확하게 존재하는지 점검.
3. **SQL 로깅**:
    
    - SQL 쿼리 실행 전, 쿼리의 실행 계획을 확인하여 조인 순서와 테이블 간의 관계가 의도대로 설정되어 있는지 점검.
    - 조인 관계에 문제가 있을 경우, 로깅을 통해 어느 부분에서 문제가 발생했는지 파악.
4. **테스트 및 검증**:
    
    - 수정 후 쿼리를 실행하여 결과가 의도한 대로 나오는지 확인.
    - 데이터의 일관성을 체크하여, 조인 후 예상된 데이터가 정확하게 반환되는지 검증.

#### 결론:

SQL에서 테이블을 조인하는 순서를 잘못 설정하면, 참조되는 컬럼을 찾을 수 없는 오류가 발생할 수 있습니다. `h_certify` 테이블과 `h_charge_complete` 테이블을 올바른 순서로 조인하여 `h_certify.return_certkey` 컬럼을 정상적으로 참조할 수 있도록 수정해야 합니다.

구글 폼 작성시 확인을 위해 이메일 발송을 하기 위해서는 

1. 구글 폼 작성 후 보내기 옆 더보기 클릭 > 스크립트 편집기 클릭합니다.

2. Apps Script 에서 Code.gs 에 아래 코드를 입력합니다.

function onFormSubmit(e) {

  var recipient = "hyunah_park@moderntec.kr";

  var subject = "모그 및 모바일 앱 수정 및 개발 요청 설문이 접수되었습니다.";

  var body = "새로운 설문이 접수되었습니다. 자세한 내용은 " +

  "링크 삽입" +

  "에서 확인하십시오.";

  

  MailApp.sendEmail(recipient, subject, body);

}

3. 시계모양 트리거 클릭 > 오른쪽 하단 '+ 트리거 추가' 클릭 > 실행할 함수 선택 > 이벤트 소스 선택 (설문지)
    > 이벤트 유형 선택 (양식 제출 시 ) 클릭 > 저장

ST_Distance_Sphere 함수에 잘못된 위도(latitude) 값이 전달된 경우 발생합니다. ST_Distance_Sphere 함수는 지리적 좌표계에서 두 지점 간의 거리를 계산하는 MySQL의 공간 함수입니다. 이 함수는 위도와 **경도(longitude)**를 입력받아 두 지점 간의 구면 거리(구의 표면에서의 거리)를 계산합니다.

문제의 원인:

• 위도 값 범위 오류: ST_Distance_Sphere 함수는 위도(latitude)가 -90도에서 +90도 사이의 값이어야 합니다. 위도의 범위는 지구상의 북극이 +90도, 남극이 -90도입니다. 위도가 이 범위를 벗어나면 "Out of range error"가 발생합니다.
• 예를 들어, 위도가 100도나 -100도와 같이 잘못된 값으로 전달되면 이 오류가 발생합니다.

해결 방법:

1. 입력값 검증:
   • ST_Distance_Sphere 함수에 전달되는 위도 값이 -90에서 +90 사이의 값인지 확인하세요.
   • 위도가 그 범위를 벗어난 값으로 전달되지 않도록 애플리케이션에서 검증하거나, 데이터베이스에서 쿼리 전에 필터링합니다.
2. 쿼리 수정:
   • 쿼리에서 위도 값을 올바른 범위로 변환하거나, 범위가 벗어난 값을 필터링하는 로직을 추가합니다.
   • 예를 들어, 위도가 90도를 초과하거나 -90도 미만인 값을 필터링하려면 WHERE 조건을 추가할 수 있습니다.
3. 위도 및 경도 값의 데이터 정합성 확인:
   • 데이터베이스에 저장된 위도와 경도 값이 올바른 범위 내에 있는지 확인하고, 잘못된 값이 저장되지 않도록 입력 데이터를 검증합니다.

예시:

SELECT * FROM locations 
WHERE latitude BETWEEN -90 AND 90 AND longitude BETWEEN -180 AND 180;

SELECT ST_Distance_Sphere
( 
  POINT(latitude, longitude)
, POINT(another_latitude
, another_longitude) 
) 
FROM locations 
WHERE latitude BETWEEN -90 AND 90 AND longitude BETWEEN -180 AND 180;

결론:

ST_Distance_Sphere 함수는 위도 값이 -90도에서 +90도 사이에 있어야 하며, 이를 벗어난 값이 입력되면 "Out of range" 오류가 발생합니다. 이 오류를 해결하려면 위도 값이 적절한 범위 내에 있는지 확인하고, 유효성 검사를 추가하거나 데이터 정합성을 점검해야 합니다