delight

요즘에 프로젝트 관련 글을 안적고 있는 것 같아서 지금까지의 일들을 요약을 해보려고 한다. 스터디 + 코드 구현 + 개인 공부 + git blog에 정리하기 이렇게 하다보니깐 tistory에 가끔 적는것 같다😅 스터디를 하면서 이를 적용할 것들이 있을까 고민하다가 프로젝트를 전부 싹 고치게 되면서 새로운 기능을 추가하기보다 더 나은 코드를 구현하고 있다. 그리고 초기에 계획을 잘 세우는게 중요하다는 것을 느끼고 있다. 초반에 계획을 작성할 때 이전 캠프에서 다른 팀에 비해 투머치로 계획 세우는데 시간을 많이 쏟아서 계획 세우는데 몇일 걸리는 것보다 구현하는데 집중하자라는 마인드로 그래서 이번 프로젝트는 큰 틀을 잡고 메인 기능 2개를 나눠서 코드를 구현하기로 했었다. 그런데 이전에 시큐리티 스터디를 하면..

고객센터 상담사 연결 채팅의 내용을 파일에 저장을 하기 위해 코드를 작성했는데 Expected BEGIN_OBJECT but was STRING at line 1 column 1 path $ 에러가 떴다. json 형식이 아닌 String 형식으로 작성되어서 생긴 오류인데 대부분 replace를 이용해서 json 형식으로 바꿔주는 방식을 사용하고 있었다. 나는 프론트에서 메세지를 보낼 때 실행되는 sendMsg() 함수를 수정해서 파일을 작성할 수 있었다. 기존 코드 function sendMsg() { let content = document.querySelector('.chat-msg').value; socket.send(content) $(".chat-msg").val('') } 변경 코드 func..

이 전에 채팅을 나가기만 하면 바로 채팅이 종료되어서 삽질을 계속 했었다. 중간에 node로 채팅을 구현해야하나 싶어서 node도 알아보고 했었다.😭 나는 백에서 채팅을 다 처리해준다고 생각해서 백의 문제로 봤었다. 그런데 의외로 프론트도 많은 일을 처리 할수도 있구나 라고 생각이 들었다. 팀원이 우리가 프론트로 처리를 안하고 백으로만 처리를 하려고 하다보니깐 이렇게 된 것 같다고 말했는데 맞는 것 같다 😅 setTimeout(function () { socket = new WebSocket("ws://localhost:8080/websocket"); }, 1000); 1초 뒤에 다시 연결해주는 것으로 작성했더니 채팅 방을 나갔다가 들어와도 여전히 채팅이 되는것을 확인할 수 있었다...!!

마지막 User와 Comment의 연관관계 매핑이 끝났다. > adme 연관관계 매핑 이론을 공부할 때는 감이 안잡혔는데 실제로 프로젝트에 적용하면서 그동안 연관관계 매핑 적용하면서 작성했던 글들을 계속 수정해갔다. 여러 test 해보면서 오류도 발견해서 해당 오류에 관한 내용도 추가하고 내용을 계속 보충해가다보니 깃 블로그에 연관관계 매핑에 관한 글들이 너무 많아지는 것 같다. - 연관관계 이론 - 연관관계 적용 - 연관관계 적용2(refactoring) - 연관관계 적용3(궁금증 해결하기) - 연관관계 적용4 정리(코드 + MySQL) 그 과정에서 - findById와 getReferenceById() - repository.findById를 작성할 때 Optional로 작성해야하는 이유 - ToEn..

기존에 이 글도 공감해주세요 게시판 코드를 refactoring했다. 2022.12.01 - [TIL] - 이 글도 공감해주세요 게시판 기능 수정 기존 코드 RegistryRepository @Query("select r.idx from Registry r") ArrayList findAllByIdx(); CommentRepository @Query("select c.registry.idx from Comment c") ArrayList findAllByRegistry_Idx(); CommentServiceImpl.java public List needComments() { List allByIdx = registryRepository.findAllByIdx(); List allByRegistry_idx..

스터디에서 getReferenceById()를 이용해서 작성했다고 하니 굳이 쓸 필요는 없고 findById()를 써도 될듯하다고 했다. 그래서 getReferenceById()도 어디서는 분명히 쓸텐데 findById()만 쓰게 되면 getReferenceById()는 있을 필요가 없지 않을까 싶어서 좀 더 찾아보게 되었다. * Git blog에도 정리했다. (내용이 더 많음) getReferenceById()는 실제 테이블을 조회하는 대신 프록시 객체만 가져온다. getIdx()를 호출하더라도 Registry를 SQL로 조회하지 않는다. → 이 경우 쿼리가 발생하지 않는다. Comment → Registry 가 LAZY 관계이면 Comment 테이블을 조회하는 시점에 registryId가 이미 FK로..

보호되어 있는 글입니다.

보호되어 있는 글입니다.

@Column은 생략이 가능하다. 팀원은 pk에 @Column을 생략했고 나는 모든 필드명에 @Column을 작성했었다. @Column에는 여러 옵션이 있는데 별다른 옵션을 설정하지 않는다면 생략이 가능하다. 즉 Entity 클래스에 정의된 모든 내부변수는 기본적으로 @Column 어노테이션을 포함한다고 볼 수 있다. name 속성을 명시하지 않으면 Entity 클래스에 정의한 컬럼 변수의 이름으로 생성이 되는데 나는 name의 속성을 사용해서 @Column을 사용했고 팀원은 사용하지 않았던 것이다. 또 nullable = false를 사용하려면 @Column을 사용하게 되는데 pk는 이미 not null이므로 name 속성을 지정하지 않는 이상 생략이 가능하다고 한다. JPA 기본 사용 문법 파악하기 ..

보호되어 있는 글입니다.