대머리개발자

너무나도 많은 정보와 비슷한 정보에 그냥 훅훅 지나가는 것이 태반이고 직접 부딪쳐서 멍드는 것이 훨 나은듯 한다. ㅎ var boardEntity = boardRepository.save(ModelMapper().map(boardDto, Board::class.java)) save 메서드를 사용 하면 알아서 create OR update를 해준다. 물론 알아서의 기준은 PK의 여부. save를 이용 하고 다시 get해서 리턴하는 구조로 작업을 했다. fun get(boardId: Long): BoardDto? { return boardRepository.findByIdOrNull(boardId)?.let {ModelMapper().map(it, BoardDto::class.java) } } 업데이트 하는..

@Bean("jasyptStringEncryptor") fun stringEncryptor(): StringEncryptor { val encryptor = PooledPBEStringEncryptor() val config = SimpleStringPBEConfig() config.setPoolSize("1") config.password = password config.stringOutputType = "base64" config.setKeyObtentionIterations("1000") config.provider = BouncyCastleProvider() config.algorithm = "PBEWithSHA256And128BitAES-CBC-BC" config.setSaltGeneratorC..

가즈아!!! 1. 코틀린에서 JPA를 사용하기 위한 추가 작업 allOpen { // 추가적으로 열어줄 allOpen annotation("jakarta.persistence.Entity") annotation("jakarta.persistence.MappedSuperclass") annotation("jakarta.persistence.Embeddable") } 2. EnableBatchProcessing 추가 @SpringBootApplication @EnableBatchProcessing class Batch02Application 3. 역시는 역시다. 그냥 되는 게 없다. ㅋㅋ 디플리케이트...ㄸ1발 다시 2번으로 돌아가서 -> @EnableBatchProcessing 제거한다. 필요 없단다.. ..

일회성 작업으로 이관 모듈을 많이 작업을 해봤다. 두고두고 재활용하려고 고민했던 기억이 있다. 고민에 대한 두 가지의 목표 1. 대부분 대량의 데이터를 이관 했기 때문에 성능적인 면을 고민 2. 정상적으로 이관이 되지 않았을 경우 예외 처리에 대한 고민 하나의 쓰레드로는 제아무리 멋드러지게 구현한다고 하더라도 멀티 쓰레드에 젭이 안 된다. 프로브 한마리랑 열마리가 자원을 캐는양이 젭이 안 되는 것처럼.... 아무튼 내가 고민했던것들이 이미 스프링 진영에서 지원하고 있던 부분이다. oauth를 작업 할 때 도 경험했던 느낌이지만 범용적으로 지원하기 때문에 투머취하다. 즉 무겁다.ㅎ 그래서 여유가 있고 코드를 짜는 즐거움을 알고 있다면.. 밑바닥부터....해보면 여러 포인트에서 충분히 재미를 느낄수 있을 것..

☆ 연관된 테이블을 조회하는 2가지 스타일 로또 테이블(lotto)과 그에 대한 통계 테이블(lottoSummary)을 조인에서 하나의 그릇으로 조회를 하고자 한다. 방법 1) 파일썬에서 잠깐 봤던 튜플이 있어서....너무 좋았다. ☆☆☆ fun getLatelyWin() : Tuple? { return jpaQueryFactory .select(lotto, summary) .from(lotto, summary) .where(lotto.turn.eq(summary.id).and(lotto.type.eq("W"))) .orderBy(lotto.type.desc()) .limit(1) .fetchOne() } 조인해서 한방 쿼리 ! Hibernate: select l1_0.id, ..., l2_0.lotto..

생각보단 쉽지 않다. ㅎ fetchOne()은 내부적으로 NULL을 리턴할 수도 있는 친구이다. 따라서 리턴값에 물음표(?)를 작성해줘야 한다. 캄파일 에러 없이 정상적이다. 물음표의 의미는 NULL 일수도 있다는 의미를 해석하는 친구한테 알려주는것이다. ☆ 근데 쿼리는 절대 NULL이 나올 수 없는 Count 쿼리이다. ( NULL -> 0) NULL일 수 있는 친구를 사용함에 있어 코틀리는 몇 가지의 조치를 진행해야 한다. Count에 대한 변수가 NULL 일 수 있으니 해당 값도 NULL 일 수 있는 값으로 받아야 하고 실제 NULL 이 아님을 코딩해야 한다. (!!).. 귀차니즘?? ## null일수는 있지만 default 값을 명시했다.. But 강제 NULL 처리를 해줘야 하는 부분은... 좀..

시작할때 부터 큰 그림을 그려서 설계서대로 하면 Best인듯 하지만 나는 바보 천치라 애자일스럽게...변덕스럽게게 클래스마다 필요 서비스를 주입하는 형태는 하드 코딩이다. 우리 고급인력이자나. 미리 주입해 놓고 가져다 쓰는 구조로 이용한다면 여러면에서 장점만 보인다. 1. 보일러 플레이트가 안 보일것이다. (여러 위치에서 서비스를 이용하기 위한 주입 코드 사라짐) 2. 유지보수 보다 쉽다. 해서 자바 플젝 할때도...서비스 Util에 모아 놓고 각 비지니스 로직에서 바로 호출 하는 구조로 사용했다. 즉, 미리 주입해놓은 친구를 가져다 쓰는 형태이다. @Component public class ServiceUtil { private static BaseService baseService; public st..

미니 프로젝트로 게시판 하나 구축 하려고 하는데 기존 했던 방식이 아닌 새롭게 해보 싶은 맘에 코틀린 JDK 1.8을 사용할 예정이라. 부트 버전을 3으로 설정할 수가 없다. ㅠ 사실상 문법만 찌금(?) 다르지... 자봐랑 똑같다고 본다. 삽질좀 해보자s 렛츠고! 프레임을 새롭게 설정하는 부분은 실상 노가다의 부분도 많다. 아파트를 만들기 위한 지반을 단단하게 만드는 과정이다. 기본적으로 설정을 해야 할 녀석들이 너무 많다.. 예외설정... 메세지 설정....설정설정....해서 멀티모듈을 설정하는 듯??.. 셋팅이 반이라고.. 잘 만들어진 길에 위에 우린 단지 숟가락만 얹이면 되는 것이다. 늘 먼저 수고스럽고 정성스럽게 작성하시는 블로그님들 감사s!!! server: port: 80 spring: pro..