학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문전에 다음을 꼭 확인해주세요. 1. 강의 내용과 관련된 질문을 남겨주세요. 2. 인프런의 질문 게시판과 자주 하는 질문(링크)을 먼저 확인해주세요. (자주 하는 질문 링크: https://bit.ly/3fX6ygx) 3. 질문 잘하기 메뉴얼(링크)을 먼저 읽어주세요. (질문 잘하기 메뉴얼 링크: https://bit.ly/2UfeqCG) 질문 시에는 위 내용은 삭제하고 다음 내용을 남겨주세요. ========================================= [질문 템플릿] 1. 강의 내용과 관련된 질문인가요? (예/아니오) 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오) 3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오) [질문 내용] 안녕하세요. 지금까지 강의를 들으면서 거의 다 스스로 풀수있을정도의 문제였는데 문제2번과같이 뭔가 자유로운 수정이 주어졌을때 어떻게해야되는지 잘모르겠습니다. 일단 다형적참조를하기위해서 Pay인터페이스를 만들어야겠구나 해서 Pay인터페이스를 만들었습니다. 그 다음부터의 처리를 나누는법이라던지 이런게 머릿속에 안떠오릅니다. PayStore에 findPay 메소드에 왜 static을 사용하는지 이해가 안 간다면 다시 static강의를 복습하고 문제를 풀 수 있을 때 다음강의로 넘어가는게 나을까요? 아니면 일단 정답 코드를 보면서 60-70%이해한상태로 다음강의로 넘어가도 될까요?
학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문전에 다음을 꼭 확인해주세요. 1. 강의 내용과 관련된 질문을 남겨주세요. 2. 인프런의 질문 게시판과 자주 하는 질문(링크)을 먼저 확인해주세요. (자주 하는 질문 링크: https://bit.ly/3fX6ygx) 3. 질문 잘하기 메뉴얼(링크)을 먼저 읽어주세요. (질문 잘하기 메뉴얼 링크: https://bit.ly/2UfeqCG) 질문 시에는 위 내용은 삭제하고 다음 내용을 남겨주세요. ========================================= [질문 템플릿] 1. 강의 내용과 관련된 질문인가요? (예/아니오) 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오) 3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오) [질문 내용] 여기에 질문 내용을 남겨주세요 .어제 까지만 해도 잘 열리던 인텔리제이가 이런 문구가 뜨면서 열리지 않습니다. 이런 오류가 종종 발생하는 이유가 뭔지 해결방법에는 어떤게 있는지 예방방법은 어떤 것이 있는지 궁금합니다
강의에서는 BoardDto로 요청을 다 받고 있는데 요청값은 CRUD마다 다를거라고 생각하는데 Request 객체의 변경이 Service 계층에 영향을 미칠 수 있기 때문에 컨트롤러랑 서비스 DTO를 다르게 준다고 알고있습니다. 컨트롤러 BoardCreateRequest BoardCreateResponse 서비스 BoardCreateDto BoardCreateResult 근데 api 하나 만들때마다 너무 많은 변환과 객체 생성이 이루어질거같은데 강사님은 실무에서 어떤 방법을 사용하시나요?!.. 궁금합니다
안녕하세요. 강의 잘 듣고 있습니다. 다름이 아니라 프로젝트 의존성 관계를 그래프로 그려주셨는데요. 그려주신 그래프가 맞는걸까요..? bank-mornitoring은 아무런 모듈을 의존하지 않고, 반대로 bank-monitoring을 의존하는 모듈은 bank-api, bank-event인데 그려주신 그래프와 관계가 좀 다른거 아닌가 싶어 여쭤봅니다!
안녕하세요 우선 값진 강의 만들어주셔서 감사드립니다. 취준을 하며 개인 프로젝트를 진행 중인데, 고민 해오던 부분들에 많은 도움이 되었습니다. 강의를 완강하고, 학습한 내용들을 바탕으로 이전에 진행했던 프로젝트의 DB를 재검토하고 재설계 해보고 있습니다. 구글링, 해당 게시판에 올라온 이전 질문들 참고하고 ai와 대화를 하고도 완전하게 확신이 서지 않는 부분이 있어서 질문드립니다. 우선 제가 만들고 있는 서비스는 "좌석이 있는 공연 예매 시스템" 입니다. 공연 데이터 생성시 해당 공연의 좌석들이 함께 생성됩니다. 즉 특정 공연의 특정 좌석들이 고유하게 생성됩니다. 그리고 사용자는 좌석을 다중 선택하여 선점하고 예매할 수 있습니다. (예매 - 좌석) 관계는 (1:N) 입니다. 그래서 기존 DB 에서는 N 쪽인 좌석이 예매 id 를 fk 로 들고 있는 간단한 형태로 진행하였습니다. 그런데 강의 중 다대다(M:N) 관계 부분에서 연결 테이블의 본질이 관계 자체를 하나의 독립된 데이터로 보고 , 그것을 테이블로 모델링 하는 것 이라는 내용을 접하고, 비록 1:N 관계이지만, 예매 - 좌석 관계가 엔티티로 승격될만 한가에 대한 고민을 했습니다. (강의에서 예시로 사용된 주문 - 주문상품 - 상품 을 보며, 좌석을 수량이 단 하나뿐인 상품이라고 생각한다면 예매 - 예매좌석 - 좌석 형태가 비슷하다고 생각했습니다.) 이유가 충분하다면 실무에서도 N:M 관계에서 뿐만 아니라 1:N 관계에서도 중간테이블 (연관엔티티)를 두는 설계를 실제로 하는지, 현재 상황에서도 (질문이 너무 길어지고 복잡해질까봐 제가 판단한 이유들을 설명드리진 않았지만) 연관관계 엔티티를 두는 것이 타당한 판단일지 고견 여쭈어봅니다. 긴 질문 읽어주셔서 감사합니다!
먼저 유사한 질문이 있었는지 검색해보세요. 서로 예의를 지키며 존중하는 문화를 만들어가요. 잠깐! 인프런 서비스 운영 관련 문의는 1:1 문의하기를 이용해주세요. 49번 문제 해설에는 david phone에 문자가 포함됐다고 하는데 문제에는 숫자만 있는 것 같습니다. 확인 부탁드리겠습니다.
안녕하세요, 공통코드 관련하여 코드그룹, 코드상세 테이블 설계 강의 잘 들었습니다. 관련하여 2가지 질문이 있습니다! 1. 혹시 사내에 dataware라는 메타시스템을 사용할 경우에는 어떤 식으로 운영을 하는지 궁금합니다. 전 회사에서는 메타시스템은 단순 정의 용도로 사용하고, 모든 코드값은 enum으로 사용을 했었는데요~ 강의 내용에 있는 것처럼 값이 바뀔 때마다 계속 재배포 작업을 해야 하긴 했지만, 그 외에 특별한 이슈는 없었던 것 같습니다. (배치성 프로젝트라 빠른 대응이 필요하지 않았음) 현 회사에서는 아직 정해진 정책은 없지만, 메타DB를 어플리케이션에서 접근할 수 있도록 하는 방법은 어떨지도 고민하고 있습니다. 그래서 일반적으로는 메타시스템, 공통코드 테이블, enum을 어떤 식으로 mix하여 사용하는지 궁금합니다. 추가로 고유한 컬럼 인식을 위해 최대한 유니크한 컬럼명을 사용하고 있는데요~ 예를 들어, 사용자로그인상태코드라는 컬럼이 있더라도 사이트에 따라 아래처럼 분리하는 경우가 존재합니다. A사이트사용자로그인상태코드 B사이트사용자로그인상태코드 이 경우 같은 아래처럼 코드값을 다르게 정의할 경우 현실적으로 체크하는 것이 좀 어려운 것 같습니다. A사이트의 경우 0:정상, 1:잠금, 2:정지, 3:휴면, 4:탈퇴 B사이트의 경우 0:정상, 1:잠금, 2:탈퇴, 3:휴면 (B사이트는 정지 상태가 없음) 같은 의미의 코드일 경우 같은 코드값을 가지게 하고 싶은데 영한님께서도 이러한 고민을 하신적이 있으신지 궁금하고 어떻게 해결하셨을지도 궁금합니다~ 감사합니다.
동시성 이슈에 발생할 수 있는 상황에서, A 변수에 대해 읽기 작업만 수행하는 코드(가시성 문제가 있을 수 있는 코드)에서는 volatile을 고려해볼 수 있고, A 변수에 대해 읽기 + 쓰기 작업도 있는 경우에는 synchronized와 atomic을 고려해볼 수 있겠네요. 제가 이해한 게 맞을까요?
먼저 유사한 질문이 있었는지 검색해보세요. 서로 예의를 지키며 존중하는 문화를 만들어가요. 잠깐! 인프런 서비스 운영 관련 문의는 1:1 문의하기를 이용해주세요. TO_CHAR(HIREDATE, 'YYYY') 대신 EXTRACT (YEAR FROM HIREDATE) 이거를 쓰는 이유가 뭘까요?
설명중에 @Version 필드를 낙관적 락에서 이용할 수 있어가지고~ 라고 하셧는데 실제 돌려보니 비관적락 2에도 DB 업데이트가 되었습니다. AI 에게 물어보니 @Version 어노테이션이 붙은 필드는 JPA 사용시 @Lock 어노테이션 사용여부 상관없이 업데이트가 된다고 합니다. 혹 다른 qna 에도 같은 내용이 있는지 확인은 모두 안해 보았습니다. ======================== 응, 같은 엔터티 row에 실제 UPDATE 가 나가면 @Version 필드는 증가한다고 보면 돼. 락 방식이 낙관적이든 비관적이든 핵심은 이거야. @Version private Long version; 이 필드가 있는 엔터티가 dirty checking으로 변경 감지 되고, flush/commit 때 UPDATE 대상이 되면 JPA/Hibernate가 version 값을 같이 갱신해. ========================
