강사님께서 작성하신 login.jsp에서는 header가 회색 계열이며, 그 header 왼쪽에는 검은색 글꼴이 배치되어 있고, 오른쪽에 정상적으로 버튼이 나오는 걸 볼 수가 있습니다. 그러나 저도 강사님께서 작성하신 login.jsp 코드를 똑같이 작성했는데 불구하고, header가 회색 계열이 아닌 흰색 계열이며, header에 구현된 버튼이 강사님께서 만든 버튼과 다른 버튼이 나옵니다. 마지막으로 bootstrap version 3.3.7버전, 그리고 jQuery 3.1.1 version을 사용했는데, 위에 언급된 문제들이 전혀 해결되지 않은듯합니다. 어떻게 하면 해결할 수 있을까요?
1. 실무에서 프로젝트 구현시 보통 폴더 구조를 어떤식으로 하시나요? 프로젝트를 하는데 폴더 구조를 어떻게 해야 좋을지 궁금합니다. 강의와 같이 api 패키지를 하나 만들고 Controller 클래스 안에 static 클래스로 dto를 만드시나요? 아니면 api 패키지 안에서 다시 패키지들로 나누시나요? 2. 별도 강의들에 대한 일정이 혹시 있으신가요? 있으시다면 언제쯤 강의를 들을 수 있을까요? 좋은 강의 올려주셔서 너무 잘 듣고 있습니다. 감사합니다.
영한님 안녕하세요. 영한님 책과 강좌를 통해서 JPA 학습에 몰입 중인데 DDD, Spring Data JPA 개념과 함께 학습을 하려고 하니 생각보다 배워야 할 내용들이 너무 많네요.. 질문 드릴 분이 영한님 밖에 없어서 한번 더 문의를 드립니다. DDD 책을 보면 Aggregate 의 리파지토리를 만들 때, Aggregate root 에 대해서만 제공하라고 하고 있습니다. 영한님 책의 예제에서 보면 Order, OrderItem, Delivery 같은 Entity 를 하나의 Aggregate 으로 묶을 수가 있고 Order 를 Aggregate Root 를 볼 수 있을 거 같은데요. 이 경우 Order 에 대해서만 Repository 를 제공할 경우, Cascade 를 사용하지 않고서는 Order, OrderItem, Delivery 를 한번에 저장할 수 있는 방법이 없을 거 같은데요.. (OrderItem 이니 Delivery 는 Repository 가 없으므로) 이렇게 Aggregate Root 에 대해서만 Repository 를 제공할 때, 혹시 Cascade 를 활용하지 않고 저장할 수 있는 방법이 있나요? 만약 Cascade 가 유일하다면 이러한 구조로 개발을 하는 것이 가장 보편적이 방법인지도 알고 싶습니다.
안녕하세요. 스프링뉴비입니다. 양질의 강의로 JPA 학습을 잘 이어오고 있습니다. 다름이 아니라, 엔티티에서 변경감지에 대해 문득 궁금한 내용이 생겨 이렇게 질문 남겨드립니다. 흔히 엔티티에 롬복 @Setter 남기지 않고 코딩을 권장하고 있습니다. 불변성을 보장하고, 불필요한 사이트 이펙트를 해결하기 위해서라는 측면에서. 이 부분은 충분히 공감합니다. 첫 스프링 토이 프로젝트로 JPA에 대해 깊히 알지 못한 채, 엔티티 특정 값을 수정하기 위해 늘 Builder패턴으로 객체를 만들어 .save(Object) 로 해당 id를 조회해서 엎어치기를 했었는데요. 이번에 변경감지를 사용하고자 했더니, setter가 아니면 안되는 것 같더라구요. 혹시 더티체크를 불변성을 어느정도 보장할 수 있는 안전성있게 할 수 있는 방법이 있을까요? 저는 주로 생성자를 통해 불변성이 보장되는 Value Object 스럽게 써왔습니다. JPA에서 더티체크를 위해서 setter를 설정해야된다는 것은 무조건일까요? 혹시 되도록 사이드이펙트가 일어나지 않도록 하는 또다른 방법은 없을까요? 더하여, 김영한강사님께서는 객체내에 setter라는 단어보다는 chageXX 이런식으로 하는 것을 권하셨던걸로 기억하는데, 혹시 맞을까요?
안녕하세요 영한님 기다리던 2편도 어제부터 너무 즐겁게 보고 있습니다 항상 좋은 강의 감사드립니다 테스트 코드 작성 중 2가지 질문이 있어 질문 드립니다 기본편 패치조인 한계편 초반에 보면 fetch join 시 별칭을 줄 수 없다고 되어 있습니다 그 이유는 별칭을 준 이후 on 에서 별칭으로 조건을 주면 OneToMany 관계에서 Collection 형태로 조회되는 데이터가 전부 조회되지 않고 일부만 나오기 때문에 문제가 생길 수 있다는 설명도 이해를 했습니다 이 과정에서 2가지 질문이 있습니다 1. 테스트를 해보면 fetch join JPQL에 on 조건을 주면 무조건 에러가 발생합니다 (with-clause not allowed on fetched association) fetch 조인 시 on 조건을 넣는 것 자체가 안된다고 생각해도 되는 것인가요? Member -> Team @ManyToOne Team -> Member @OneToMany 2. 1번 질문에서 만약 fetch 조인 시 on 조건 자체가 불가능하게 설계 되었다면 Collection의 값이 항상 보장되는 쿼리는 실행이 되어야 하지 않을까 해서 설계상의 원칙인지 제가 놓치고 있는 부분이 있는지 궁금합니다 ex) Select t from Team t join fetch t.member m on m.name=:memberName (memeber 컬렉션이 전부 조회되지 않기 때문에 실행 불가능 한 것을 이해) ex) Select t from Team t join fetch t.member m on t.name=:teamName (Team을 기준으로 조건을 주었기 때문에 member Collection에는 영향이 없어 문제가 없지 않을까? 라고 생각합니다) 3. fetch 조인 시 where문 사용 의견 fetch 조인 시 where 조건은 동작하는 것을 테스트에서 확인했습니다 1) OneToMany 조건에서 where 조건을 Collection이 아닌 조건에만 사용 하는 것 ex) Select t from Team t join fetch t.member m where t.name=:teamName 2) ManyToOne, OneToOne에서 where 조건을 양쪽 모두 사용 하는 것 ex) Select m from Member m join fetch m.team t where m.name=:memberName Select m from Member m join fetch m.team t where t.name=:teamName 위처럼 사용하는 것에 대한 의견 부탁드립니다 그리고 QueryDSL 강의 기다리고 있습니다 ^^
부모엔티티에서 자식엔티티를 mappedby로 양방향 잡으면 readonly로 데이터 생성 변경 모두 불가하지만 cascade를 사용하면 가능하다라고 이해하는게 맞는건가요? 반대로 자식엔티티에 조인된 부모엔티티에 cascade하고 자식엔티티에 부모엔티티넣으면 pk뿐만 아니라 부모도 함께만들어 진다 즉, 방향성이든 주인이든 상관없이 같이 영속상태가되어 저장된다고 이해하면 맞을까요?
예제에서는 Entity에 Setter가 존재하여 Entity class 내에 set이 가능했지만... 강의에서 강조했듯이 Setter를 제거하고 DTO를 사용을 하게된다면 연관관계 메서드는 DTO내에 존재하게 되는건가요? 아니면 생성자나 builder를 통해서 set 하게 되는걸까요?
안녕하세요 선생님 좋은 강의 너무나 감사드립니다. 다름이 아니고 강좌 듣는도중 궁금한 부분이 있어 질문드립니다. 이전 강의 "도메인 모델과 테이블 설계" 강좌와 이번 강좌내용에서 ORDERS와 DELIVERY는 OneToOne 단방향 매핑이라고 이해를 하였는데 [그림1] - 엔티티 클래스 개발1 강의 내용중 회원엔티티 분석 설계도중 일부 [그림2] - 도메인과 모델과 테이블 설계 강의 내용 강의 29분경 실제 엔티티를 설계하는 부분에선 mappedby를 사용하여 OneToOne 양방향 매핑한거 같아 질문드립니다. [그림3] Order 엔티티 [그림4] Delivery 엔티티 아직 학생인데 선생님 덕분에 JPA를 쓰는 회사로 취업하고싶네요. 좋은 강좌 정말 감사합니다.
FAILURE: Build failed with an exception. * What went wrong: Execution failed for task ':test'. > No tests found for given includes: [jpabook.jpashop.MemberRepositoryTest](filter.includeTestsMatching) * Try: Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights. * Get more help at https://help.gradle.org BUILD FAILED in 4s 테스트 맴버 실행 도중에 위와 같은 오류가 발생하였습니다. 뭐가 문제인걸까요? ㅠ
안녕하세요. spring security 권장사항이 BCrypt라고 해서 조금 찾아보고 테스트를 해봤는데요. <첫 번째 시도> password = !@#$password1234 passwordHashed = $2a$10$foL9uBBw3knu9QoKmVb64.pRTRsxy96NQUQanjhOzl8D1yEoLs73m isValidPassword = true <두 번째 시도> password = !@#$password1234 passwordHashed = $2a$10$abpfdjC6qWnj687evfjzx.bV0Xlkas7wcx0s8OT2UwQD1Huo54oyi isValidPassword = true 보면 솔트를 랜덤으로 생성하기 때문에 인코딩된 패쓰워드가 다르게 나오는데 어떻게 인증이 되는건가요..? 어.. 그러니까 만약 Bcyrpt 솔트 기본값 10으로 회원등록을 하고 (첫 번째 시도) 이 걸로 다시 로그인을 하면 두 번째 시도의 값이 나와서 두 개가 다르다고 인식을 할 거 같은데 어떻게 옳은 패스워드로 스프링 시큐리티가 판단하는지 궁금합니다. 아니면 솔트를 사용하는게 아닌건지..궁금합니다.
A->B->C 로 참조가 되어 있어서 A를 지우려면 B를 먼저 삭제하고 B를 지우려면 C가 먼저 삭제되어져야 한다고 했을 때, 만약 C가 A를 참조하게 될 경우 싸이클이 생겨서 서로 삭제가 안되는 문제가 생기는데인. 웹던이나 DB단에서 c->a로 참조를 걸려할 때 잘못된 것으로 인지하고 막고 싶은데. 보통 이럴때는 어떤식으로 해결을 해야하나요?