[질문 템플릿] 1. 강의 내용과 관련된 질문인가요? (예 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예 3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예 [질문 내용] 컬렉션의 필요성에 대해 질문 좀 드리겠습니다 - 인프런 | 질문 & 답변 (inflearn.com) 여기서 궁금한 내용있습니다!. 1)"생각하신 내용이 맞습니다. 중간 테이블을 중심으로 조회가 가능하다면 크게 문제가 없습니다. 하지만 때때로 중간 테이블을 중심으로 조회하기 어려운 경우들도 있습니다." 김영한 강사님의 답변 내용 중에 떄떄로 중간 테이블을 중심으로 조회하기 어려운 경우가 어떤 경우인지 구체적으로 알려주실수 있나요?? 일단 다대다=>중간테이블 필요=>성능 최적화 필요하면=>중간테이블에 해당하는 리포지토리 생성후 (Spring data JPA에서) @Query(fetch join)사용하는식으로=> 맨날 이런식으로 했었는데 중간 테이블 중심으로 조회하기 어려운 경우가 어떤 경우인지 궁금합니다. 2)BatchSize를 사용하는 경우 일대다의 일의 collection에 해당하는 다( members) 를 일의 BatchSize에 해당하는만큼 가지고 오지 않습니까? for (Team team : teams) { System.out.println("team:"+team.getName()); for(Member mem:team.getMembers()){ System.out.println(mem.getUsername()); } } 여기서는 성능 최적화가 이해가 됩니다!. team이 붙어있으므로 배치 사이즈만큼만은 mem.getUsername()이 호출되어도 또 그때동안은 쿼리가 안나가니깐요. 근데 궁금한게 IN 쿼리에 들어가는게 BatchSIze만큼의 TeamID인데 연속한 ID만큼 나가는 걸로 알고 있는데 위처럼 연속한 경우는 몰라도, Team을 이것저것 조회하고 그에 대한 member의 메서드를 호출하면 이게 성능상 좋은가요?
학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문전에 다음을 꼭 확인해주세요. 1. 강의 내용과 관련된 질문을 남겨주세요. 2. 인프런의 질문 게시판과 자주 하는 질문(링크)을 먼저 확인해주세요. (자주 하는 질문 링크: https://bit.ly/3fX6ygx) 3. 질문 잘하기 메뉴얼(링크)을 먼저 읽어주세요. (질문 잘하기 메뉴얼 링크: https://bit.ly/2UfeqCG) 질문 시에는 위 내용은 삭제하고 다음 내용을 남겨주세요. ========================================= [질문 템플릿] 1. 강의 내용과 관련된 질문인가요? 예 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? 예 3. 질문 잘하기 메뉴얼을 읽어보셨나요? 예 [질문 내용] start.spring.io 에서 spring boot를 설치하고 h2 버전도 1.4.199로 설치하였습니다. 그러나 아래의 사진과 같이 라이브러리 내에 h2:1.4.199가 아닌 h2:2.1.214가 설치되어 있습니다. 이 부분 때문에 다음 강의에서 제대로 실행이 되지 않는 것 같습니다 .. (MEMBER 테이블 생성이 되지 않음) 왜 이러는 걸까요 ..? 해결 방법도 알려주시면 감사하겠습니다 ㅜ ㅜ
안녕하세요. 강의를 듣고 강의자료까지 참고하며 코드를 작성하였습니다. 그러나 실행창에 create와 drop이 뜨지도 않고 MEMBER 테이블 또한 생성되지 않습니다. 관련 질의를 지금 6시간 넘게 다 찾아보며 (띄어쓰기, @Rollback(false) 추가 등) 해결 시도를 했지만 끝까지 되지 않아 질문 남깁니다 .. [yml 코드] 감사합니다 ..
@Beanpublic SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception{return http.authorizeHttpRequests().requestMatchers("/auth/login").permitAll() .anyRequest().authenticated() .and().csrf(AbstractHttpConfigurer::disable) .build(); } 기존의 강의에 나온 위 코드를 실행하게 되면, This is because there is more than one mappable servlet in your servlet context: {org.springframework.web.servlet.DispatcherServlet=[/], org.h2.server.web.JakartaWebServlet=[/h2-console/*]}. 위와 같은 DispatcherServlet과 h2-console의 서블릿이 하나 이상 매핑되어 나는 오류라고 나옵니다. @Bean public SecurityFilterChain securityFilterChain(HttpSecurity http, HandlerMappingIntrospector introspector) throws Exception{ http.authorizeHttpRequests((authz) -> { try { authz .requestMatchers(new MvcRequestMatcher(introspector,"/auth/login")).permitAll() //애는 권한 없이도 허용 .anyRequest().authenticated() //나머지는 인증해 .and() //csrf쪽으로는 builder가 이어지지 않기 때문에 and로 이어준다. .csrf(AbstractHttpConfigurer::disable); } catch (Exception e) { throw new RuntimeException(e); } }); return http.build(); } 그래서 검색 결과 위와 같이 작성하게 되면 정상적으로 실행되게 됩니다. - 질문 제가 코드를 기존에 SecurityFilterChain 외 잘못 작성한 부분이 존재해서 위와 같이 코드를 작성해야 하는 것인지, 아니면 그 사이에 이렇게 작성되도록 변경된 것인지 앞으로도 지속적으로 검색해보겠지만... 현재까진 답을 찾지 못해 질문드립니다. 2. h2-console의 경우 데이터베이스 관련 서블릿이고, DispatcherServlet은 웹 애플리케이션의 컨트롤러 역할을 하는 서블릿인걸로 알고 있는데 용도가 다른 두 서블릿의 매핑 혼동이 일어나는 이유가 궁금합니다... *무지한 한 생명체의 질문은 천천히 쾌차하시고 삶의 여유를 되찾으신 다음 답변해주시면 감사하겠습니다!
안녕하세요 강의명-소스브랜치 정리한 엑셀 파일에서 3) 어노테이션 권한 설정 - @PreAuthorize, @PostAuthorize, @Secured, @RolesAllowed 강의의 브랜치명이 ch05-9가 아니라 ch05-8인것 같습니다. Account 클래스의 userRoles에 붙은 어노테이션이 8에서 9로 넘어갈때 달라져서 강의 내용이 재연이 안됩니다. 확인 부탁드립니다.
JPQL를 데이터를 조회하면, DB에 먼저 조회한 후, 영속성 컨텍스트에 이미 동일한 엔티티가 있으면, DB에서 조회한 데이터를 버리고, 이미 있는 엔티티를 반환한다고 알고 있습니다. 만약, 기존 엔티티를 새로 검색한 엔티티로 대체한다면, 영속성 컨텍스트에 수정 중인 데이터가 사라질 수 있어, 위험하다고 하는데, 그러면, 조회시 수정 중인 데이터가 조회되어서, 의도치 않는 데이터가 조회될 수 있지 않나요? 오히려 수정 중인 데이터 대신 새로 조회한 데이터로 대체하는게 좋지 않을까 싶은데, 혹시, DB에서 조회한 데이터를 버리고, 이미 있는 엔티티를 반환하는게 더 장점인 구체적인 예시가 있을까요?
제가 아직 초보 개발자라 막연히 setter 사용은 지양하는게 좋다고 배워서 실무에서는 다른지 궁금합니다. setter 를 열어두면 빈으로 등록된 AppConfig 의 불변성을 보장할 수 없게 되는게 아닌가 해서 질문드립니다. https://mangkyu.tistory.com/189 위 블로그를 보면 @ConfigurationProperties 를 setter 없이 생성자로 할 수도 있는것 같아서요. 혹시 제가 너무 setter 사용을 지양하라는 말에 매몰돼있는건 아닐까 고민도 되네요.
안녕하세요! 강의영상에서는 가능한 많은 예제를 보여주려고 다양한 연관관계 매핑을 사용했다고 하셨는데 단방향을 지향하는 실무 관점에서 궁금한게 있습니다. Order N:1 Member => 다대일 단방향이 가능한지 OrderItem N:1 Order => 다대일 단방향이 가능한지 Order와 Delivery 관계에서 단방향이 안되는 이유 Item과 Category를 일대다, 다대일로 풀어내는게 맞는지 답변해주시면 감사하겠습니다!!
안녕하세요 강사님 4) 웹 기반 인가처리 DB 연동 - FilterInvocationSecurityMetadataSource (1) 수업을 듣다가 질문드립니다. FilterSecurityInterceptor에서 AuthenticationManager 주입 받는 이유가 궁금합니다. 인증은 앞의 필터를 지나면서 이미 완료가 되었고, FilterSecurityInterceptor는 인증이 끝난 뒤에, 권한 정보를 조회해서 체크하는 곳이고, 인증 정보는 SecurityContextHolder에서 꺼내면 되는데, AuthenticationManager로 뭘하려고 주입받는 것인지 궁금합니다. AbstractSecurityInterceptor 코드를 살펴보니, authenticateIfRequired 메서드에서 SecurityContextHolder에서 꺼낸 Authentication 객체가 isAuthenticated 가 false일때 AuthenticationManager에 Authentication 객체를 넘겨서 재인증을 시도하고 있습니다. private Authentication authenticateIfRequired() { Authentication authentication = SecurityContextHolder.getContext().getAuthentication(); if (authentication.isAuthenticated() && !this.alwaysReauthenticate) { if (this.logger.isDebugEnabled()) { this.logger.debug("Previously Authenticated: " + authentication); } return authentication; } else { authentication = this.authenticationManager.authenticate(authentication); if (this.logger.isDebugEnabled()) { this.logger.debug("Successfully Authenticated: " + authentication); } SecurityContextHolder.getContext().setAuthentication(authentication); return authentication; } } 그런데, 이미 앞에서 인증 과정을 거친 결과가 isAuthenticated == false인 상태에서, 재인증을 시도하는 것이 무슨 의미가 있는지 궁금합니다. 결과가 달라지는 케이스가 있는건지, 재인증이 목적이 아닌건지... 아니면 인증을 처리하는 필터가 앞에 없을때를 가정하는건지...궁금합니다. 답변 주시면 감사하겠습니다.
class Member( ... ) { @OneToMany(fetch = FetchType.LAZY, mappedBy = "member") ⬅️Q1:"cascade 없음 이유" val memberRole: List<MemberRole>? = null ⬅️Q2: "null 초기화"(mutableListOf() 누락) } Q1: cascade 미사용: 강의 컨샙에 맞춰 쉬운 예제 구성을 목적으로 컬랙션 필드에 Cascade 설정을 안하신게 아닐까 추측했지만, 한편으로 다른 구현방법에 대한 다른이유가 있으신 것인지 강의에 언급되지 않은 부분을 여쭤보고 싶었습니다. Q2: 컬랙션 null 초기화: 일반적인 JPA 예제에서는 JpaEntity 의 1:N 관계 필드는 Collection 초기화를 하더라구요. null 로 초기화 할 때의 장점 이라던지, 다른 이유가 있는지 궁금해서 남기게 되었습니다. 읽어주셔서 감사합니다.
Kevin의 알기 쉬운 Spring Reactive Web Applications: Reactor 1부
안녕하세요. Backpressure의 Drop 전략에서 버퍼가 비워질 때까지 Emit된 데이터가 Drop이 된다는 것은 이해했습니다. 그런데 1번 데이터가 subscriber에게 전달되어서 처리가 되면 버퍼에 자리가 한 자리 비게 되는데 왜 데이터가 계속 Drop이 되는건가요? (코드 실습에서 onNext()함수가 호출이 되어도 255,256,257 ~ 1024까지 모두 드랍됨) | 1, 2 | <-------- 3 듣랍 | 2, |. <-------- 4 드랍 (여기서 왜 4번 데이터는 안들어가나요?) | 5, 6 | Buffer DROP-LATEST를 보면 | 1, 2 | <---- 3들어오는 중 버퍼 가득 차서 drop | 2, 4 | <------ 1번이 버퍼에서 나가고 한 자리가 비어서 4번이 들어와짐 이런식으로 동작을 하는데 Drop은 이렇게 동작하지 않는 것 같아 버퍼가 어떻게 동작하는지 궁금하여 질문드립니다.
실전! 코틀린과 스프링 부트로 도서관리 애플리케이션 개발하기 (Java 프로젝트 리팩토링)
강사 님께서는 객체를 인스턴스화 하실 때, 생성자를 사용하거나, 정적 팩토리 메서드를 사용하는 방식 2가지를 이용하셨는데 혹시 코틀린에서 builder 패턴을 사용하는건 어떻게 생각하시나요?? defalut 파라미터를 이용하고 naming을 통해 builder패턴 처럼 사용할 수 는 있겠지만 java에서 builder패턴을 통해 객체를 만들었던 것에 비하면 불편하다는 생각이듭니다. 조언 해주시면 감사하겠습니다.
안녕하세요, 강의를 보고 공부를하다 궁금한 점이 생겨 질문드립니다. 제가 예측한 강의 내용으로는, "경쟁 상태 예시(재고 수량)에 대하여 레디스 를 활용한다." 라고 예측 했습니다. 이에 대하여, "레디스는 싱글 스레드 기반이니깐, 락킹 없이 해당 작업이 가능할 것" 이라고 추측하였는데요, 그러나 제가 생각지 못한 레디스 lock 과 관련된 내용을 접하게 되어 신기하면서도 또 궁금한 부분이 생겨 질문드립니다. 레디스 락 전략이 사용되는 이유와 예시를 조금더 들어볼 수 있을까요? 혹은 이와 관련하여 추가적으로 공부해볼 수 있는 자료를추천해주시면 감사하겠습니다.
갱신된 강의자료에도 나와 있듯이, fetchResult, fetchCount 등의 메소드는 deprecated 예정입니다. 또한 해당 메소드는 Page 타입을 반환하기 때문에 Page 타입을 직접적으로 조작해야 한다는 제약이 있습니다. 이걸 잘 쓰면 되는데, Page 의 시작번호 등 제약도 있어서 저는 회사에서 Page 를 따로 만들어서 사용하거든요. 그래서 search 메소드와 count 메소드는 항상 분리하고 있습니다. 2. 그런 점에서 count 만 최적화하는 로직만 베껴서 만든 최적화 메소드입니다. 실제로 count 구문을 실행하기 위한 메소드입니다. 필요에 따라서 public 으로 만들어도 될 것 같네요. // count 실행 메소드 private Long countByCond(MemberSearchCond cond) { return query .select(member.countDistinct()) .from(member) .where( usernameEq(cond.getUsername()), teamNameEq(cond.getTeamName()), ageGoe(cond.getAgeGoe()), ageLoe(cond.getAgeLoe()) ) .fetchOne(); } 최적화 로직을 베낀 메소드입니다. 스프링 데이터 JPA 는 아래 코드와 같이 page, size 값이 null 이 아니고, 적절한 범위에 있는지를 판단하여 isPaged 라는 분기를 만듭니다. 참고로 코드를 분석하면서 내린 뇌피셜이니 혹시 틀리다면 말씀해주세요. page 가 0 이 아니라 1 부터 시작하는 건 제 취향입니다. 회사에서 그렇게 쓰고 있거든요. 필요에 따라 0 부터 시작하도록 바꾸는 건 어렵지 않을 것 같습니다. public Long countByCondOptimization(List<?> content, MemberSearchCond cond, Long page, Long size) { boolean isPaged = page != null && size != null && page > 0 && size > 0; long offset = isPaged ? (page - 1) * size : 0L; long contentSize = content.size(); if (!isPaged || offset == 0) { if (!isPaged || size > contentSize) { return contentSize; } return this.countByCond(cond); } if (contentSize != 0 && size > contentSize) { return offset + contentSize; } return this.countByCond(cond); } 이렇게 하여 count 쿼리를 리스트 조회 쿼리와 분리하여 재사용성을 높이면서, 성능도 최적화할 수 있습니다. 감사합니다.
강의에서는 Query DSL 4.x 버전이어서 제네릭 없는 예제 코드인 것 같은데, 제가 올리는 버전은 5.0 버전이어서 차이가 있음을 감안해주세요. 정렬 조건을 하나만 추가하는 코드입니다. 정렬 조건을 여러 개 추가하려면 반복문을 돌면서 JPAQuery 를 동적으로 확장해나가면 됩니다. // 페이징하는 메소드에서 사용 private Expression<? extends Comparable<?>> specifyMemberProperty(String prop) { prop = prop == null ? "" : prop.toLowerCase(); if (prop.equals("username")) { return member.username; } if (prop.equals("age")) { return member.age; } return member.id; } // 페이징하는 메소드 // ... .orderBy(new OrderSpecifier<>("desc".equalsIgnoreCase(dir) ? Order.DESC : Order.ASC, specifyMemberProperty(prop))) .fetch(); -- 저는 일단 이렇게 만들어봤는데, 다른 분께서 더 나은 코드, 더 빠른 코드가 있다면 저한테도 알려주세요. 감사합니다.
