Member와 StudyRoom의 관계 매핑을 지으려고 생각하다보니, 두 엔티티의 관계는 일대다, 다대일 관계가 아니라 다대다임을 알게 되었다. 물론 @ManyToMany를 써서 두 엔티티를 매핑하는 것이 이론적으로 불가능한 것은 아니다.

자동 로그인 기능을 구현하기 위해 filter 와 interceptor 를 활용해서 자동 로그인 체크를 한 사용자와 그렇지 않은 사용자를 걸러내려고 했습니다. 하지만 이 과정 자체를 일일이 로직으로 쳐내는 것이 복잡했고

이번 프로젝트는 상용화 서비스를 만들기 위함은 아니었지만, 학습 차원에서 메세지, 국제화 기능을 적용해보았습니다. 또한 제대로 작동하는지 확인을 위해 테스트 코드 작성까지 완료했습니다.

스프링 부트는 src/main/resources/templates 경로에서 템플릿을 찾는다. 하지만 만약에 모든 템플릿이 예를 들어 new-templates 폴더 안에 들어가도록 변경해야하는 요구사항이 들어왔다고 하자. 그러면 어떻게 해야할까?

처음으로 Controller, Service, Repository 별로 격리된 환경에서 단위 테스트 코드를 작성하다보니 모든 게 낯설고 생소했습니다.

부가 기능을 핵심 기능이 있는 Controller, Service, Repository Layer에 넣어도 좋을까? 답은 No이다. 생각해봐도 반복 코드가 넘칠 것 같고, 수정할 일이 생기면 너무 복잡할 것 같았다.

채팅 기능을 구현하는데, 어떤 사용자가 어떤 메세지를 입력했는지 보여주려고 한다. 메세지 내용 전달에는 성공했으나, 어떤 사용자가 그 내용을 입력했는지 즉 채팅방의 유저 정보를 전달하는데 어려움을 겪고 있었다.

SLF4J는 Simple Logging Facade for Java 라는 이름에서부터 알 수 있듯이, Logback, Log4j2와 같은 Logging Frameworks의 추상화 역할을 해요. 추상화 로깅 라이브러리이기 때문에 단독으로는 사용할 수 없어요.

프로그램 개발이나 운영 시 발생하는 문제점을 추적하거나 운영 상태를 모니터링하기 위해 작성하는 텍스트를 로그라고 해요. 그리고 이를 남기도록 시스템을 만드는 것을 로깅이라고 하죠.

퍼사드 패턴은 객체 지향 프로그래밍에서 자주 사용되는 소프트웨어 디자인 패턴이에요. 건축에서의 facade(건물의 정면)와 유사하게, facade(퍼사드)는 내부적으로 혹은 구조적으로 더 복잡한 코드를 가려주는 상위 수준의 인터페이스의 역할을 하는 객체라고 하네요.

네트워크의 혼잡 원인을 해결하기 위해서는 네트워크의 혼잡을 일으키는 송신자를 억제하는 매커니즘이 필요하다. 네트워크의 혼잡이 데이터 송신과 수신속도 그리고 효율에 어떻게 영향을 미칠 수 있는지 알기 위해 세 가지 시나리오를 살펴본다. 비현실적이지만, 라우터가 무한 버퍼

자바 ORM 표준 JPA 프로그래밍(책), 자바 ORM 표준 JPA 프로그래밍 - 기본편(인프런강의) 을 공부하면서 정리하는 글입니다. JPA에서 객체와 테이블을 매핑하는 방법은 두가지가 있다. 첫번째는 XML을 사용하는 것 두번째는 어노테이션을 사용하는 것이다. 이번 글에서는 어노테이션 사용법에 대해서만 알아볼 것이다. @Entity 테이블과 매핑할...

어떻게 JPA는 DB 정보를 인식할까? JPA는 persistence.xml 을 사용해서 필요한 설정 정보를 관리한다. 이 설정 파일은 반드시 META-INF/persistence.xml 경로에 있어야 한다. property 즉 속성부분에 적어줘야 하는 것은 필수 값과 옵션이 있다. 필수값 JPA 표준 속성 javax.persistence.j...

동적 파라미터화는 아직 어떻게 실행할지 결정하지 않은 코드 블록을 의미한다.

객체와 RDB, 그 패러다임 불일치로 인해 발생하는 구체적인 문제는 무엇인지에 대해 살펴봅니다.

JPA는 무엇이고, 왜 필요한가 그리고 SQL에 의존적인 개발은 어떠한 단점이 있는가. 이에 대해 살펴봅니다.

Java의 예외 클래스 구조를 살펴보면 모든 예외 클래스는 Throwable 클래스를 상속받고 있으며, Throwable은 최상위 클래스 Object의 자식 클래스이다. 그리고 Throwable을 상속받는 클래스는 Error와 Exception이 있는데,

실전 프로젝트에서 아직 코딩으로 기능을 구현하기 전, 팀원들과 함께 데이터 모델링을 할 때였다. User 테이블에는 Refresh Token 필드값을 넣어뒀었고, 채팅 기능을 구현하기 위해 Chatroom과 Chat 테이블까지 만들어뒀었는데 한 팀원이 이런 질문을 던졌

문제의 발단은 이러한 고민에서부터 시작되었다. "프론트에서 요청한 데이터가 짜여진 DB 구조상 엄청나게 중첩되어 있을 때, DTO를 여러개 만들어서 프론트에 데이터를 주고 있는데, 이렇게 되면 쿼리가 여러개 날라가게 되잖아. 물론 불필요한 쿼리를 조회하는 것은 아니니

1차 정규화: 1차 정규형은 각 로우마다 컬럼의 값이 1개씩만 있어야 한다. 이를 컬림이 원자값을 갖는다고 말하는데 만일 하나의 컬럼이 2개 이상의 값을 가지면 1차 정규형을 만족하지 못한다고 말한다. 그리고 2개의 값이 있었던 것을 1차 정규화하게 되면 데이터 red