강의 영상 24분쯤 fetch join은 페이징 처리가 불가능하다고 말씀해주셨는데(사용하게 될 시 메모리에 임시로 모든 데이터 적재 후 페이징 처리로 설명), 페이징을 하지 않을 경우에도 Order rows가 1만건 이라면 1만건 모두 조회되는 것 아닌가요? 이럴 때도 메모리에 대한 문제가 있을 것 같은데 제가 잘못 이해한 것인지 설명 부탁드리겠습니다!
안녕하세요 선생님. 33분 대 자바 문제에서 제가 이해한 바가 맞는지 궁금해 질문 드립니다. ------------------------------------ 업캐스팅 되지 않은 상태로 obj가 태어났고 child() 생성자를 찾으러 올라갔고, 업캐스팅 여부와 상관 없이 새로 객체가 태어나게 되면 child()를 실행하기 전에 -> 자동으로 parent()로 올라가게 됩니다. parent() 안에 있는 this(500)으로 인해 parent(500)을 실행하게 되고, parent의 int x가 100에서 500으로 바뀝니다. 그리고 다시 child()로 돌아와서 this(5000) -> child(5000) -> child.x는 4000에서 5000으로 바뀌게 됩니다. 다시 메인으로 내려와서 system.out.println(obj.getX())를 실행하게 되고 child 클래스에는 getX가 없기 때문에 parent 클래스로 올라가서 getX()를 찾습니다. 그래서 return x로 인해 parent의 500을 답으로 돌려주게 됩니다. --------------------------------- [질문] 1. 제가 위에 적어놓은 풀이과정이 맞나요? 2. 업캐스팅 여부와 상관 없이, 업캐스팅 됐든 되지 않았든 새로 객체가 태어나게 되면 child()를 실행하기 전에 -> 자동으로 parent()로 올라가게 되나요? 3. 만약 Child obj2 = new Child(300) 이렇게 태어나게 되면 Child(int x)로 올라갔다가 -> 자동으로 Parent(int x)로 올라가게 되나요? 아니면 이 경우는 기본생성자 형태가 아니기 때문에 super로 부모를 명시해야 하나요? 4. system.out.println(obj.getX())를 실행할 때, child 클래스에 getX가 있었다면 메서드 오버라이딩으로 인해 parent 클래스로 올라가지 않나요? 질문이 너무 많은 거 같은데 죄송합니다.. 다시 한 번 개념을 정립하고 싶어 길게 질문드렸습니다. 답변 주시면 감사하겠습니다..
안녕하세요 선생님. 항상 강의 잘 듣고 있습니다! 다름이 아니고 빈칸 채우기 정렬 문제에서 2번에 nx가 아니고 5라고 써도 정답 처리가 될까요?? 문제에서는 a[]의 길이가 5이고 해당 문제에서는 이미 문제가 명시되었기 때문에 다른 배열이 올 수가 없는 상태이니 5라고 적어도 되지않을까 궁금합니다!
현재 Member 도메인 모델 확장 까지의 수업을 듣고 궁금한 것이 있습니다! 저희가 이번 수업을 포함하여 지금까지 요구사항(도메인) -> 도메인 모델(회원) -> 비밀번호 해시 라는 일련의 과정을 통해 비밀번호 암호화와 관련한 도메인 모델의 규칙, 속성, 행위 등을 뽑아냈기 때문에 비밀번호 암호화까지 도메인 로직에 포함된다고 이해했습니다. <인터페이스 위치를 결정하는 기준에 대해> 해당 답변에서도 PasswordEncoder를 어디에 둘지 결정할 때 사용한 기준은 도메인 모델을 이야기할 때 이게 등장하는가 라고 말씀해주시기도 했고요! 그렇다면 개발은 결국 요구사항을 토대로 진행되는 것이기에 모든 코드가 도메인 로직으로 분류되어야 하는 것 아닌가? 하는 의문점이 생겼습니다! 토비의 생각을 듣고 싶습니다!
안녕하세요. 8분쯤 양방향 연관관계 시 @JsonIgnore 어노테이션을 통해 순환 참조가 되는 것을 방지해야 한다고 알려주셨는데, 엔티티 하나하나 들어가서 직접 확인해야 하나요? ERD나 관계가 복잡해서 까먹을 경우 이렇게 하나씩 확인을 해야 하는지, 아니면 IDE 같은 걸로 도움을 받을 수 있는지 궁금합니다.
이번 강의에서 GenerateLabel 클래스를 생성할 때 초기화에서 input_dir과 output_dir에 대해서 형식을 path로 미리 지정해주었습니다. 그런데 아래 validate_path 함수에서 추가적으로 if not all~ 구문을 사용해서 해당 인자들의 형식을 확인하도록 코드를 구성하셨는데 이러한 이유가 따로 있으신가요? 만약 해당 형식이 아니면 처음 클래스를 초기화할 때부터 에러가 발생하지 않나요? 항상 좋은 강의 만들어주셔서 감사드립니다.
안녕하십니까. 높은 질의 강의를 준비해주셔서 감사합니다. 강의를 들으면서 현재 강의에서 최종적으로 만들고자 하는 MLOps 아키텍쳐 과정에서 궁금한 것이 생겨 이렇게 질문을 하게 되었습니다. 강의에서 '지도학습을 위한 라벨링 데이터를 만들기 어려운 상황이 많기 때문에 LLM을 통해서 라벨링 데이터를 만들겠다.'라는 느낌으로 말씀을 하셨는데 그렇게 되면 해당 데이터로 학습을 한 모델은 위에서 사용된 LLM의 성능에만 근접하도록 튜닝이 되는 것이지 않을까요? 궁금한 점을 좀 더 자세히 말씀드리면, LLM으로 anomaly detection을 수행하면 되는데 어떤 이유에서 LLM으로 만든 데이터셋을 예측하는 머신을 추가적으로 만들어야하는 이유를 잘 모르겠습니다. LLM API의 Latency 때문일까? 라는 생각을 했지만 정확하지 않은 것 같아 질문을 남기게 되었습니다. 좋은 강의 항상 감사드립니다.
안녕하세요 강의 잘 듣고 있습니다. 섹션2 12번 강의에서 ( 관심사 기반의 뉴스 레터 발행 / 구독 모델 ) 에서 질문 있습니다. fanout exchange는 바인딩된 모든 큐에 메시지를 보내는 방식이므로 모든 큐에 메시지가 가는 것으로 알고 있습니다. 예를 들어 제가 java 라는 특정 topic을 구독하면 java queue 에 있는 메시지만 계속 소비할텐데, 그러면 나머지 spring queue나 vue queue 에는 메시지가 계속 쌓여 문제가 되는 것 아닌가요 ? 발행/구독 모델을 왜 fanout exchange로 구현하신 건지 궁금합니다.
안녕하세요:) 강의를 듣고 궁금한 점이 있어 질문드립니다. 44강과 45강에서 List에 대해 설명해 주시면서 일반적인 상황에서는 ArrayList나 LinkedList를, 동시성 문제가 고려되어야 하는 상황에서는 Vector를 사용하라고 말씀해 주셨습니다. 그런데 Vector는 JDK 1.x 시절에 도입된 레거시 클래스로 모든 public 메서드에 synchronized 키워드가 적용되어 있어 성능 저하와 불필요한 락 경쟁, 캐시 무효화 등의 문제가 발생할 수 있는 것으로 알고 있습니다. 그래서 현재는 java.util.concurrent 패키지에서 제공하는 동시성 컬렉션이나, Collections.synchronizedList, CopyOnWriteArrayList와 같은 대안들을 상황에 맞게 사용하는 것이 더 적절하다고 알고 있습니다. 이러한 이유로 단순히 동시성 문제를 고려해야 하는 상황에서 Vector를 권장한다라는 접근은 현재 시점에서 어울리지 않는다고 생각됩니다. 그럼에도 강의에서 Vector를 언급하신 특별한 의도나 배경이 있으셨는지 궁금하여 질문드립니다 :)
사진과 같은 문제에서 답은 부모 클래스라고 하는데, 함수 호출과 인스턴스 생성을 구분해서 질문하지 않은 질문 같아서 글을 올려봅니다. 콜 스택에서 자식 클래스 생성자 -> 부모 클래스 생성자 함수 순으로 콜이 쌓이고, 먼저 쌓인 부모 클래스의 생성자 함수가 실행이 되면서 부모 인스턴스가 생성 -> 자식 인스턴스가 생성이 되는거라고 생각합니다. 즉, 제가 생각하는 답은 자식 클래스인데 제가 옳게 판단한건지 확인차 문의드려봅니다.
[질문 템플릿] 1. 강의 내용과 관련된 질문인가요? (예) 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예) 3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예) [질문 내용] 안녕하세요. 좋은 강의 잘 수강하고 있습니다. 16강과 17강 강의가 저에게는 이해하기 어려워서 다음과 같이 정리해보았습니다. 맞게 잘 적은건지 피드백 부탁드리겠습니다 ! 엔티티의 XxxToOne 관계는 모두 패치조인 한다. row 수를 증가시키지 않기 때문이다. XxxToMany(컬렉션)는 페이징을 하지 않고 조회되는 데이터가 적을 시에는 패치조인을 해도 된다. 단, N 쪽에 수 많은 데이터가 있다면 성능 최적화를 고려해야 하기 때문에 페이징 기법을 사용할 수 있으니 패치조인은 사용하지 말자 왜냐하면 모든 데이터를 DB에서 읽어오고, Hibernate는 1:N 조인 결과를 모두 메모리에 가져온 다음 1을 기준으로 페이징을 메모리에서 다시 수행해야 한다. 이때, 수백만개의 데이터라면 애플리케이션은 메모리 부족으로 OOM이 발생할 수 있다. 컬렉션은 지연 로딩으로 조회하는데 성능 최적화를 위해 hibernate.default_batch_fetch_size, @BatchSize를 적용한다. IN 쿼리를 통해 한꺼번에 설정한 size 만큼 조회할 수 있다. 장점 : row 수가 많아지는 단점을 가진 패치 조인보다 DB 데이터 양이 최적화 된다.
안녕하세요 토비님. 강의 정말 잘 보고 있습니다. 다름이 아니라 Auto Increment 전략을 현업에서도 자주 사용하시는지 궁금해서 문의드립니다. Mysql에서 Auto Increment를 사용하니 bluk insert가 안되는 구조던데 문제가 있으셨던 적은 없는지 궁금합니다. bluk insert를 jdbc template으로 구현했더니 갈레라 3중화 구조라 ID가 3씩 증가하는 문제가 있어서 곤란한 경험이 있습니다. 이럴 경우 ID 전략을 UUID나 Snowflake 이런식으로 가져가야 하는지 궁금합니다. 아니면 다른 해결 방법이 있으시다면 알려주시면 감사하겠습니다.