우리집앞마당

이전 포스팅에서 id 프로퍼티를 어느 위치에 선언하는게 좋을지 얘기해봤다. 이번엔 Long 과 Long? 중 어떤걸로 선언할지, 어떤차이가 있는지, 그리고 왜 이런 고민을 하게되는지 얘기해보려한다. # Long? vs Long @Entity @Table(name = "person") class Person( @Column(name = "person_name") val name: String, @Id @GeneratedValue(strategy = GenerationType.IDENTITY) @Column(name = "person_id") val id: Long? = null ) id 값의 생성을 DB 에 위임하는 IDENTITY 방식을 주로 사용할텐데 이 방식을 사용하면 엔티티가 영속화되기 전에는 id..

자바에서 entity 를 정의할 때는 id 를 어떻게 선언할 것인지에 대한 고민을 크게 할 필요 없었다. 보통 인스턴스 필드 선언부의 가장 최상단에 정의했을 것이다. @Entity @Table(name = "person") public class Person { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) @Column(name = "person_id") private Long id; @Column(name = "person_name") private String name; } 하지만 코틀린에서 정의할 때는 이런저런 고민을 하게된다. 아마도 코틀린이 자바보다 다양한 문법을 지원하고 있다보니 괜시리 더 고민이 되게 되는 것 같다. @Entity @Ta..

# 이슈 코틀린에서 테스트 작성시 mock 객체가 필요하면 mockk 를 사용하고 있다. 아마도 가장 대중적인 mock 프레임워크 아닐까 싶다. 얼마전 mockk 를 이용해 테스트를 작성하다가 동료 개발자와 신기한 현상을 발견했는데 간략화하면 아래코드와 같다. class Simple1 { fun simple1(): String { return "hello world" } } class Simple2( private val simple1: Simple1, ) { fun simple2(): String { return simple1.simple1() } } class MockkApplicationTests { @Test fun mocking() { val simple1 = mockk() val simple2..

처음 코틀린을 접한지 5년이 다되어가고 있다. 물론 실제 현업에서 사용한건 그 반정도 밖에 안되지만 말이다. 그동안 코틀린이라는 언어에 대한 본연의 기능과 그 외 코틀린용 라이브러리, 자바 프레임워크와 코틀린과의 궁합 등등에 대해 학습은 하면서도 테스트만큼은 계속 Junit 만을 이용해오고 있었다. mock 라이브러리인 mockito 와는 이런저런 궁합문제로 진즉에 mockk 로 넘어갔지만 Junit 과 assertion 라이브러리인 AssertJ 에 대해선 크게 불편함을 못 느꼈던게 그 이유가 아닐까 싶다. 여튼 kotest 자체는 오래전부터 알고있었으나 뒤늦게 한번 훑어보기로했다. kotest 는 크게 3개의 모듈로 구분된다. 이 모듈들에 대해 간단하게 알아보자. 1. Test Framework 테스..

이전에 이런 포스팅을 한 적이 있다. ( kotlin(+JPA) entity 에서 setter 를 막을 수 있을까 ) 결론을 암울하게 끝낸 것 같아서 몇가지 해결법을 포스팅하고자 한다. 1. 프레임워크에 의존하지 않는 domain layer @Entity @Table(name = "product") class Product( @Column(name = "product_name") var name: String, @Column(name = "product_price") var price: Long, @Id @GeneratedValue(strategy = GenerationType.IDENTITY) @Column(name = "product_id") val id: Long? = null, ) { fun up..

자바 백엔드 진영에서 로그는 이미 slf4j 가 평정했다. slf4j 를 기반으로 log4j, logback, log4j2 등 구현체들이 사용되고 있는 중이다. 코틀린에서도 유사하게 사용하면 되는데 아래와 같이 로깅할 수 있다. logger.info("1+1 = {}", variable) 기존 로거에서 {} 와 같이 템플릿을 지원한건 로그 레벨에 따른 레이지 연산을 지원하기 위해서였다. 가령 예를 들어 logger.info("1+1 = " + variable) 이렇게 작성하면 메세지와 변수 variable를 더하는 연산이 무조건 실행된다. 이 무조건이라는 표현은 애플리케이션 로그 레벨이 warn 으로 설정되어 info 레벨의 메세지를 로그를 남기지않아도 되는 환경에서도 실행된다는 의미이다. 다만 첫번째 ..

# 이슈 annotation class CustomAnnotation 위와 같이 커스텀 애노테이션을 정의한다. 애노테이션은 다양하게 활용할 수 있지만 내 의도는 프로퍼티에 사용하려는 의도라고 가정한다. class Person( name: String, ) { @CustomAnnotation val name: String = name } @Test fun findAnnotation() { val person = Person3("LichKing") val properties = person::class.memberProperties for (property in properties) { if (property.name == "name") { assertThat(property.hasAnnotation())...

kotlin + jpa 를 사용할때 가장 고민되는 것중 하나는 entity 에 class 와 data class 중 어떤걸 사용하는가에 대한 선택이다. 사실 class 를 이용할때는 아무런 이슈가 없다. data class 를 사용하고 싶다는 의문?유혹? 이 들때 이런 고민을 하게 될텐데 몇가지 우려되는 부분들을 확인해보자. 1. spring guide spring guide 에서는 JPA 는 data class 가 제공하는 메서드들을 염두하고 작성되지 않았으므로 class 를 사용하라고 한다. Here we don’t use data classes with val properties because JPA is not designed to work with immutable classes or the m..

java 에서 사용되는 json 라이브러리로 jackson 과 gson 이 대표적이다. 특히 spring boot 에서 디폴트 라이브러리로 채택되어있는 jackson 을 많이 사용할 것이다. 백엔드 개발에서 kotlin 을 사용할때도 java 생태계를 대부분 그대로 이용하므로 jackson 을 주로 사용하게된다. kotlin 에 맞춰 제작된 KotlinModule 만 넣어주면 크게 문제 없이 사용할 수 있다. jetbrains 에서는 기존 java 생태계 라이브러리가 아닌 자체적인 kotlin native 라이브러리를 제공하고있다. kotlinx.serialization 이 그것인데 간략하게 한번 알아보자. # kotlinx.serialization 일단 kotlin serialization 은 두 가지..

kotlin 에서 java 프레임워크(대표적으로 spring, hibernate)를 이용할때 가장 문제가 되는건 상속이다. java 프레임워크들은 상속을 적극적으로 이용해서 개발자들의 코드를 확장하는데 kotlin 은 기본적으로 final class 이기때문에 상속이 되지않기때문이다. open 키워드를 붙이면 상속이 되게되는데 이를 수작업으로 할 경우 빼먹기도 쉽고 일일이 타이핑을 해줘야한다는 불편함이 존재한다. 이를 해소하기위해 jetbrains 에서 kotlin-allopen 이라는 플러그인을 지원하고있다. IDE 에서 언어를 kotlin 으로 지정해 spring 프로젝트를 생성하면 기본적으로 들어가는 플러그인이기때문에 저 플러그인을 제대로 인지하지 못하고 있어도 자연스럽게 개발하는데 문제가 없게되기..