학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문전에 다음을 꼭 확인해주세요. 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인데 그려주신 그래프와 관계가 좀 다른거 아닌가 싶어 여쭤봅니다!
동시성 이슈에 발생할 수 있는 상황에서, A 변수에 대해 읽기 작업만 수행하는 코드(가시성 문제가 있을 수 있는 코드)에서는 volatile을 고려해볼 수 있고, A 변수에 대해 읽기 + 쓰기 작업도 있는 경우에는 synchronized와 atomic을 고려해볼 수 있겠네요. 제가 이해한 게 맞을까요?
해당 강의 수강중에 정환님께서 진행해주신 부분 그대로 똑같이 따라했는데 화면에서는 아예 아무것도 보이지않는.. 출력이 안됩니다..ㅠㅠ 무슨 문제일까요?? 예상은 api를 저장하는 auth.ts 부분부터 뭔가 잘못된거같은데 이유를 모르겠습니다. (그리고, 예외사항으로 import 부분의 빨간밑줄오류나 코드에서 오타가 아닌 빨간밑줄오류는 왜 생기는걸까요??ㅠ) 현재 진행중인 코드를 한번에 알아보기 쉽게 Github에 바로 올렸습니다. 링크 : https://github.com/Skyllerrr 안에 Repository의 첫 번째 프로젝트(onebite-SNS)입니다.
설명중에 @Version 필드를 낙관적 락에서 이용할 수 있어가지고~ 라고 하셧는데 실제 돌려보니 비관적락 2에도 DB 업데이트가 되었습니다. AI 에게 물어보니 @Version 어노테이션이 붙은 필드는 JPA 사용시 @Lock 어노테이션 사용여부 상관없이 업데이트가 된다고 합니다. 혹 다른 qna 에도 같은 내용이 있는지 확인은 모두 안해 보았습니다. ======================== 응, 같은 엔터티 row에 실제 UPDATE 가 나가면 @Version 필드는 증가한다고 보면 돼. 락 방식이 낙관적이든 비관적이든 핵심은 이거야. @Version private Long version; 이 필드가 있는 엔터티가 dirty checking으로 변경 감지 되고, flush/commit 때 UPDATE 대상이 되면 JPA/Hibernate가 version 값을 같이 갱신해. ========================
안녕하세요. 우선 좋은 강의 제작해주신 토비님께 항상 감사하고 있어요. 이제 배운지 1년된 왕초보입니당.. 혼자 배워보면서 개인 프로젝트를 만들고 있는데 JPA를 사용하고 있어요. 제가 궁금한 것이... N+1 관련한 문제입니다. 아 일단 프로젝트 주제는 복식부기 가계부에요. @Entity ... public class Journal extends BaseEntity { @ManyToOne(fetch = FetchType.LAZY) @JoinColumn(name = "ledger_id", nullable = false, updatable = false) @OnDelete(action = OnDeleteAction.CASCADE) private Ledger ledger; ... @OneToMany(mappedBy = "journal", fetch = FetchType.LAZY, cascade = CascadeType.ALL, orphanRemoval = true) private List<EntryLine> entries = new ArrayList<>(2); ... public EntryLine getEntryLine(EntrySide side) { switch (side) { case CREDIT : this.entries.stream().filter(line -> line.isCredit()).findFirst() .orElseThrow(...); case DEBIT : this.entries.stream().filter(line -> line.isDebit()).findFirst() .orElseThrow(...); default : throw new ... } } ... // Service에서 저장되기 전에 호출 public void validateSavable() { ... validateJournalSave(); } private void validateJournalSave() { AccountType debit = getEntryLine(EntrySide.DEBIT).getAccountType(); AccountType credit = getEntryLine(EntrySide.CREDIT).getAccountType(); if(!this.transactionType.isValidPlacement(debit, credit)) { throw new ... } } } Journal Class에서 EntryLine List에 접근하고 있어요. 그리고 EntryLine Class는 이렇게 생겼어요. @Entity ... public class EntryLine extends BaseEntity { @ManyToOne(fetch = FetchType.LAZY) @JoinColumn(name = "journal_id", nullable = false, updatable = false) private Journal journal; @ManyToOne(fetch = FetchType.LAZY) @JoinColumn(name = "account_id", nullable = false) private Account account; ... // private package 접근제어자 사용 // Account는 Category를 참조중이에요. AccountType getAccountType() { return this.account.getCategory().getAccountType(); } } 거래가 저장되기 전에 Journal : validateJournalSave() 에서 this.transactionType에 따라 차변과 대변에 올바르게 위치하고 있는지 검사한 후 저장하고 있는데 이것을 생성과 수정할 때 두 곳에서 사용하고 있어요. Ledger에 5개 Category가 있고, Account는 그 Category를 참조하고 Category에서만 AccountType이 있어요. Journal이 각 EntryLine의 AccountType을 얻기 위해 Journal -> EntryLine -> Account -> Category -> getAccountType() 이렇게 흘러가네요. 이렇게 접근해도 설계상 괜찮은걸까요? Journal을 저장할때는 @Query 사용해서 Fetch Join으로 필요한 Account를 가져오고 있는 상황이에요. Journal이라는 엔티티가 비즈니스 로직 수행을 위해서 다른 엔티티의 필드까지 깊게 참조?? 가져오도록 설계하는게 옳은건지 모르겠어요.
