쁘도리의 블로그

Spring 개발을 하다보면 mapper.xml 에 간혹 ' WHERE 1=1 ' 을 보게 된다. 

where 1=1 은 어떤이유 때문에 소스에 사용 되는지와 사용하지않는다면 어떤 대안이 있는지 알아볼까 한다..

( 필자는 where 1=1 을 사용시 DB실행에 불필요한 수식연산이 들어가여 자원을 잡아먹어 선호하지 않는 의견을 몇번 들어보긴 하였다.. )

WHERE 1=1 참(ture)을 의미

쿼리의 조건을 동적으로 사용하기위해 사용한다고 한다.

하지만, DLETE(삭제), UPDATE(수정) 기능을 수행하는 쿼리에서는 null판별이 옳바르게 전처리 작업이 수행되지 않는 상황에서 삭제나 수정 기능에 사용한다면 원치않는 결과를 초래할수 있다고한다. 왜냐하면 1=1 은 참이기때문에 모든 데이터를 삭제하거나, 모든데이터를 수정하는 일이 발생할수 있기때문이다.

정리하자면, 대부분에 동적인 상황을 고려하여 WHERE 1=1을 사용하는 경우가 대부분의 사용하는 이유가 될것이라고 필자는 생각한다, 하지만 의도치않는 예외적인 상황이 발생한다는 점을 고려한다면 좋은 방법은 아닌것이라고 생각이된다.

WHERE 1=1 에대해서 사용하는 이유와 반대로 WHERE 1=1 을 사용하지 말아야 한다는 이유를 찾다가 잘 정리된 2개의 블로그 게시글이 있어 공유한다. (판단은 본인이...)

WHERE 1=1 의 대안으로는 <where> 태그와 <c:if>  태그를 사용하여 대체하는 방법을 권고한다.

예시 

WHERE 1=1 
 and user_id = #{userId}

<where>
    <if test="userId != null and userId != ' ' ''> 
        and user_id = #{userId}
    </if>
</where>

마지막으로 해당 mybtais 동적SQL에 대한 자세한 내용은 mybatis 공식사이트에서 확인할 수 있다.

@RequestBody,  @RequestParam, @ModelAttribute

@RequestBody : 클라이언트가 전송하는 JSON(application/json) 형태의 HTTP Body를 JAVA객체로 변환시켜주는 역할,

 Body가 존재하지 않는 HTTP Get 메소드에 @RequestBody를 활용하려고 한다면 에러가 발생한다. @RequestBody로 받는 데이터는 Spring에서 관리하는 MessageConverter 중 MappingJackson2HttpMessageConverter를 통해 JAVA객체로 변환하는데, 이는 ObjectMapper 라는 클래스를 이용한다.

@RequestParam : 1개의 HTTP요청 파라미터를 받기 위해서 사용한다. @RequestParam은 필수 여부가 true이므로 반드시 해당 파라미터가 전송되어야 하며, 파라미터가 전송되지 않으면 400에러를 발생한다. (필수값이 아닌경우 required를 false로 설정하는 방법이 있으며, defaultValue옵션을 사용하면 기본값 역시 지정 가능하다.)

@ModelAttribute : 클라이언트가 전송하는 multipart/form-data 형태의 HTTP Body와 HTTP 파라미터의 값들을 생성자나 Setter를 통해 주입하기 위해 사용된다. @ModelAttribute에는 매핑시키는 파라미터의 타입이 객체의 타입과 일치하는지를 포함한 다양한 검증(Validiation) 작업이 추가적으로 진행되는데, 예를 들어 게시물의 번호를 저장하는 int형 index 변수에 "1번" 이라는 String형을 넣으려고 한다면, BindException이 발생하게 된다.
@ModelAttribute을 사용해서 특정 Parameter 값 만을 가져올 수도 있다.

* ObjectMapper의 동작과정 : ObjectMapper는 Json 메세지를 자바 객체로 변환하는 과정에서 객체의 기본 생성자를 통해 객체를 생성하고, 내부적으로 Reflection을 사용한다. 그래서 반드시 @Setter가 필요한 것은 아닌데, @Getter나 @Setter 혹은 @JsonInclude 등 필드에 있는 변수들의 이름을 찾기 위한 메소드들을 필요로 한다.

 그러므로 기본생성자 + @Getter로 클래스를 구현해주면 @Setter가 없어도 값이 바인딩된다.

출처: https://mangkyu.tistory.com/72 [MangKyu's Diary:티스토리]MangKyu's Diary:티스토리]

BufferedReader, StringTokenizer 는 문자열로 활용하기 위하여 사용. BufferedReader를 사용하는 것이 Scanner를 사용하는 것보다 빠르다.
BufferedReader는 문자열에 최적화 되어 있음.

BufferedReader
readLine() 입력값으로 들어온 데이터를 한줄로 읽어서 String으로 바꾸는 메소드 /단, 무조건 한줄만 읽는다

close() 입력작없이 끝나면 close 로 입력스트림을 닫고 사용하던 자원을 해제
+ 추가적으로 BufferedReader를 사용하려면 예외처리를 해주어야한다 IOException throws처리 

BufferedWriter
write() 출력할 내용 담기
flush() 버퍼를 비워내는 동시에 콘솔에 출력 /write()만 사용한다고 콘솔에 출력되는게 아니라, 반드시 flush를 써줘야햐 한다
close() 출력이 끝나면  close로 스트림을 닫음

StringTokenizer
BufferedReader는 잘라서 배열과 같이 인덱스를 사용하여 접근하여 사용.
StringTokenizer는 공백이 있다면 뒤에 문자열이 공백 자리를 땡겨 채우도록 한다.
StringTokenizer가 BufferedReader보다 빠르게 사용될 수 있다.
문자열을 자르게 위해 split을 사용할땐, split은 정규식을 기반으로 자르는 로직으로서 내부는 복잡하다. 그에 비해 StringTokenizer의 nextToken()메소드는 단순히 공백 자리를 땡겨 채우는 것이다. 그렇기 때문에 속도 차이가 날 수 밖에 없다.
정규식이나 인덱스 접근과 같은 처리가 필요없다면 StringTokenizer를 사용하는 것이 효율적이

static 변수

1. 항상 값이 변하지 않는 경우 메모리 이점이 있음

 > 변수에 Static을 선언하면 JAVA는 메모리 할당을 한번만 할당하여 메모리 사용에 이점이있음

* 선언한 변수의 값이 변경되지 않길 원한다면 static 앞에 final을 선언하면 됨

  > final 선언시 선언한 값을 변경하지 못하게됨, final 선언된 값을 변경 할 경우 예외발생

2. 공유의 개념 (변수값 공유) 

   대부분 변수값을 공유하고자 static을 이용

static 메소드

 static 메소드 안에서는 인스턴스 변수 접근이 불가능

단, static변수일 경우 static메소드에서 접근이 가능

[응용] Singleton pattern (싱글톤 패턴)

단 하나의 객체만을 생성하게 강제하는 패턴 

try {
			InputStream is;
			is = Runtime.getRuntime().exec( 파일경로 ).getInputStream();
			BufferedReader br = new BufferedReader(new InputStreamReader(is, "MS949"));
			
			result = 1;
			
			br.close();
			is.close();
		} catch (IOException e) {
			e.printStackTrace();
		}

참고 : https://computersj.tistory.com/entry/JAVA-%EB%82%A0%EC%A7%9C-%EB%B9%84%EA%B5%90-date-compare

String a == String b  << 문자열을 비교하는것이아니라 a, b 의 주소값을 비교하는것

문자열을 비교하기위해선 .equals 메소드사용하는것을 권장

ex) a.equals(b)

JAVA 파일확장자 추출 split (X), Substring(O)

ex) 

substring(fileOrgNm.lastIndexOf(".")+1,fileOrgNm.length());

회사 프로젝트에 lombok.jar를 통하여 개발한 프로젝트가있어 구글링하던 중

잘 정리 된 포스팅 글을 찾아 공유하여 정보를 제공합니다.

참고 사이트 : http://countryxide.tistory.com/16

Show history를 통하여 

변경된 소스보는 과정을 잘 정리하신 티스토리사이트가 있어 공유합니다.

출처 : http://ggari.tistory.com/183