안녕하세요, 김영한 강사님.페치 조인 시 페이징을 시도하면 메모리에서 프로세싱이 이루어지기 때문에 Out of Memory가 일어날 수 있다고 말씀주셨는데요. 이 이유가 정렬 시 추가적인 메모리 공간을 사용하기 때문인가요? 대량의 데이터를 페이징 없이 쿼리하면 메모리를 거치지 않고 결과값을 내려주나요? 페이징 없이 쿼리를 하더라도 메모리를 통한다면 수 많은 데이터를 쿼리하더라도 Out of Memory가 일어날수 있는게 아닌가 싶어서요. 혹시 제가 디비 쿼리 원리를 잘못 이해하고 있는걸까요. 감사합니다.

안녕하세요. 핵심원리를 듣고 이번 강의를 들으면서 배운 것을 적용하려고 시도해보았습니다. Service interface와 Repository interface를 생성하여, componentscan을 사용하여 빈을 등록하려고 했습니다.  기존 service와 repository를 Impl로 바꾸어 @Component 어노테이션을 붙여 의존관계를 자동 주입하려고 했습니다.  ``` @Component@Transactionalpublic class MemberServiceImpl implements MemberService { private final MemberRepository memberRepository; @Autowired public MemberServiceImpl(MemberRepository memberRepository) { this.memberRepository = memberRepository; } ``` @Componentpublic class MemoryMemberMemberRepository implements MemberRepository { @PersistenceContext private final EntityManager em; @Autowired public MemoryMemberMemberRepository(EntityManager em) { this.em = em; }@Configuration @ComponentScan( excludeFilters = @ComponentScan.Filter(classes=Configuration.class))public class AppConfig {} @Testpublic void 회원가입() throws Exception{ //given AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class); 해당 코드를 테스트를 시도하였지만  No qualifying bean of type 'javax.persistence.EntityManager' available: expected at least 1 bean which qualifies as autowire candidate. Dependency annotations: {} 이라는 오류가 발생하였습니다.  개념이 많이 부족하여 질문을 제대로 했는지도 정확하지않고, 해당 오류가 왜 나는지 잘 모르겠습니다 ㅠㅠ 

강의를 듣고 질문들을 보면서 저나름 정리한 내용인데 확실히 맞는지가 궁금합니다. ! 1. Test에서 데이터변경이 일어나기에 @Transactional 에너테이션으로 트랜잭션시작을 지정한 상황에서 MemberService의 join메서드가 실행되면 join메서드도 @Transactional 에너테이션이 있어도, 동일한 트랜잭션으로 인식한다. (트랜잭션 내부의 트랜잭션이여도 동일한 트랜잭션) 2. 그렇다면 MemberServiceTest 트랜잭션과 MemberService의 트랜잭션이 동일한 트랜잭션이기에 스프링은 동일한 EntitiyManager를 제공하므로, 동일한 영속성 컨텍스트에 접근하기때문에, 엔티티 동일성을 보장한다. (요부분은 궁금한 내용입니다!) 3. spring boot를이용하면 @PersistenceContext로 EntitiyManagerFactory로부터 EntitiyManager를 받아오는것을 지원하는데, spring data jpa를 이용하면 스프링 컨테이너에서 스프링 빈 DI하는것과 같이 생성자주입(여타 다른 주입도 상관없음,, 필드주입,, setter주입)을 통해서 EntitiyManager를 받아올수있다고 하셨는데, 그럼 EntitiyManager가 스프링빈과같이 스프링 컨테이너에 존재한다는 의미인가요??? 항상 잘듣고있습니다. 읽어주셔서 감사합니다.

커넥터는 도커로 사용하지 않나요?

`익명 사용자` 라는 것이 그냥 보기에는 접속이 가능한 것처럼 보였지만, 강의와 여러 QnA 를 다시 보다알게된 결론으로 정리를 해보았습니다. Spring Security 에서의 `익명사용자` 개념 정리 인증이 되기 전이나, 이후 의 사용자 모두유효한 인증토큰을 갖고있지 못하면 `익명 사용자`이다 `익명 사용자`는 로그인이 가능한 경로를 통해 인증허가를 을 받게 될 경우, 일반 사용자로 등극하여, 로그인 접속 및 향후 접속유지가 가능하게된다. 인증을 받지 못한 사용자는 `익명 사용자`로 분류되어, `익명 사용자` 인증 토큰이(인증 객체) 익명 사용자 관리 명목으로 생성되지만, 로그인과 관련된 접근 권한은 없다(세션 생성이 되지않음) -> `redirect /login page` `익명 사용자` 전용으로 발급된 인증토큰을 통해, 향후 `익명 사용자` 접근 여부를 관리 할 수 있다  틀린 부분이 있다면 조언을 구합니다. 감사합니다.

안녕하세요. DDD Start라는 책을 함께 읽으며 영한님의 강좌를 다시 한번 보고 있습니다. 그러던 도중 과연 어디까지 비즈니스 로직으로 보아야할까에 대한 의문점이 생겼습니다. 책에서는 도메인(엔티티) 쪽에 비즈니스 로직을 두고 서비스 레이어는 각 도메인의 함수를 호출하는 형태로 구현하여 서비스를 최대한 얇게 만들어야한다고 하더라구요. 그런데 이번 강의 2분 49초쯤을 보면 중복 회원을 검증하는 코드가 서비스 레이어에 위치해있습니다. 회원가입이라는 기능에서 중복 회원 검증이라는 규칙은 서비스에 있어 핵심 비즈니스 로직이라고 생각하는데요. 이 부분을 엔티티쪽에 두어 검증하지않고 서비스 레이어에 두셔서 혼란이 오더라구요. 질문을 요약하자면,  1. 중복 회원 검증 코드는 비즈니스 로직이라고 봐야할까요? 2. 맞다면 비즈니스 로직은 엔티티에 들어가야 하지 않나요? 3. 요구사항에는 중복 검증뿐만 아니라 수많은 검증 로직들이 존재할텐데, 이를 서비스에 작성해야할지 엔티티에 작성해야할지 어떠한 기준으로 판단해야할까요? 4. 도메인(엔티티)에서는 레포지토리를 호출하면 안된다고 알고 있습니다. 현업에서는 이를 명확하게 지키면서 코드를 작성하나요? 5. 만약 4번이 맞다면, 중복 회원 검증의 경우 실제 데이터베이스에 조회하는 쿼리를 날려야합니다. 이렇게 데이터베이스에 접근해야하는 로직의 경우 엔티티에 작성하면 안되는걸까요? (모든 질문은 DDD를 기반으로 질문드립니다!) 많은 예제들을 살펴보아도 서비스레이어에 작성할지 엔티티쪽에 작성할지 기준을 잡기가 정말 힘드네요.. 이 부분에 대해서 영한님의 의견을 듣고 싶습니다. 감사합니다 :)

윈도우 환경에서 gradle로 빌드 하시려는 분들을 위해 공유 드립니다. 1. build.gradle dependencies { ... classpath "com.github.node-gradle:gradle-node-plugin:3.1.0" } classpath에 node-gradle 을 추가해 주시고 def preinstalledNodeDistributionDirectory = file("${projectDir}/src/main/resources/static/node") 이거 하나 선언해 주시고 apply plugin: "com.github.node-gradle.node" 위 플러그인 적용해주시면 node { version = '11.15.0' // 제가 사용중인 노드 버전을 적었습니다. download = true nodeModulesDir = file("${projectDir}/src/main/resources/static") } task copyFrontLib(type: Copy) { from "${projectDir}/src/main/resources/static" into "${projectDir}/build/resources/main/static/." } copyFrontLib.dependsOn npmInstall compileJava.dependsOn copyFrontLib 해당 코드를 추가하여 사용하시면 build시에 프런트 라이브러리들을 빌드에 추가하실 수 있습니다. 2. css 깨짐 현상 본 강의와 같이 부트스트랩을 사용하셔서 동일한 css를 적용시키려면 그냥 install bootstrap으로는 안되는것같습니다.  버전이 달라서 css 속성명이 달라졌나봐요... 그래서 만약에 build에 정상적으로 라이브러리 추가 되시는데 뷰가 어디가 좀 깨져서 나오시거나 css가 적용이 잘 안되시면 "dependencies": { "bootstrap": "^4.4.1", "jquery": "^3.4.1" } 선생님이 강의에서 사용하신 버전으로 명시적으로 바꾸어주셔야 합니다.  저렇게 적용하면 정상적으로 뷰가 나와요... 많이 해맸네요ㅜㅜ

이미 상품이 발송되었을 때 IllegalStateException이 발생하게 되어있는데, 이에 대한 처리는 없는 것 같아서 질문드립니다.그리고 만약에 이것에 대해 처리해주는게 맞다면 처리는 어떻게 해야할까요??

안녕하세요 선생님 강의 잘 듣고 있습니다. Delivery에 Address가 있는데 이 값은 Delivery에 있는 Order를 참조하고 그 안에 있는  Member를 참조하면 가져올 수 있지 않나요 ?  참조가 너무 많이 일어나기 때문에 Address를 Delivery에 선언하는건가요 ?? 

안녕하세요! 강의에서 기존 테스트를 통합 테스트로 변경하면서 생성자 주입 코드가 필드 주입 코드로 변경되었는데요 @Autowired MemberService memberService;@Autowired MemberRepository memberRepository; 필드 주입으로 변경한 후 MemberRepository를 Autowired 받는 부분은 주석 처리를 해도 테스트 코드가 정상적으로 수행되더라고요 @Autowired MemberService memberService;// @Autowired MemberRepository memberRepository; 생각을 해보니 MemberService를 Autowired할 수 있다는 건 MemberService 빈이 이미 생성되어 있다는 거고 MemberService 빈이 생성되려면 MemberService 생성자의 매개변수로 받을 MemberRepository가 필요하기 때문에 MemberRepository 빈도 이미 생성되어 있다는 거고 결국 MemberRepository 빈을 전달하면서 MemberService 빈을 생성했기 때문에 이후부터는 필드 주입이든 생성자 주입이든 MemberService를 Autowired하기 위해 MemberRepository가 함께 쓰이지 않아도 될 것 같더라고요 혹시 아니라면 MemberRepository를 주입받는 코드의 용도가 따로 있는 건가요?

강사님 항상 좋은 강의 감사합니다! 연관관계 편의 메소드에 내부에 set과 add , get이 각각 들어갈때가 다르길때 혹시 어떤 경우일때 set이고 get인지 알고 싶습니다. 제가 생각했을때는  1) member엔티티와 order 엔티티 간 setMember메소드에서 member는 다대일 중 '다'이므로 setMember 메서드를 만들어야 했던건가요? 2) 마찬가지로 그렇다면 order와 orderItem 사이에서 orderItem은  일대다 의 '일' 이므로 addOrderItem()메서드가 생성되었다 생각을 했는데 그렇게 따지니 setDelivery() 메서드가 이해가 가지 않습니다. 일대일의 관계로 '일'에 위치해 addDelivery()인가 싶기도 하였으나 그렇지 않더라고요 ㅠㅠ 3) setDelivery()메서드는 set으로 시작하는 setMember() 메서드와 같은 방식으로 작성하는 것인가 했는데 메서드 내부에서는  this.delivery = delivery; //배송지 설정delivery.setOrder(this); 이렇게 set메서드와 add메서드가 섞여있는 것 같은데 이해가 많이 부족한 것 같습니다.. 혹시 이에 관해서 답변해주실 수 있을까요?

안녕하세요 선생님 지금까지 실행은 잘 되다가  크롬에서 http://localhost:8080 이 안되서  어제 application.properties 에 server.port=8082 로 변경하여  잘나왔었는데 또 무언가를 잘 못건드렸는지 사이트에 연결할 수 없음 localhost에서 연결을 거부했습니다. 다음 방법을 시도해 보세요. 연결 확인 프록시 및 방화벽 확인 ERR_CONNECTION_REFUSED 이렇게 나옵니다. 포트 번호를 다른것으로 바꿔도 위와 같이 나오는데 이유가 무엇인가요??

wsl2 리눅스에서 서버를 startup 하였고 정상적으로 실행은 되었습니다. startup 후에 localhost:8083/connectors호출 하면 아래와 같은 에러가 발생합니다. org.apache.kafka.connect.errors.ConnectException: Failed to find any class that implements Connector and which name matches io.confluent.connect.jdbc.JdbcSourceConnector, available connectors are: PluginDesc{klass=class org.apache.kafka.connect.file.FileStreamSinkConnector, name='org.apache.kafka.connect.file.FileStreamSinkConnector', version='6.1.0-ccs', encodedVersion=6.1.0-ccs, type=sink, typeName='sink', location='classpath'}, PluginDesc{klass=class org.apache.kafka.connect.file.FileStreamSourceConnector, name='org.apache.kafka.connect.file.FileStreamSourceConnector', version='6.1.0-ccs', encodedVersion=6.1.0-ccs, type=source, typeName='source', location='classpath'}, PluginDesc{klass=class org.apache.kafka.connect.mirror.MirrorCheckpointConnector, name='org.apache.kafka.connect.mirror.MirrorCheckpointConnector', version='1', encodedVersion=1, type=source, typeName='source', location='classpath'}, PluginDesc{klass=class org.apache.kafka.connect.mirror.MirrorHeartbeatConnector, name='org.apache.kafka.connect.mirror.MirrorHeartbeatConnector', version='1', encodedVersion=1, type=source, typeName='source', location='classpath'}, PluginDesc{klass=class org.apache.kafka.connect.mirror.MirrorSourceConnector, name='org.apache.kafka.connect.mirror.MirrorSourceConnector', version='1', encodedVersion=1, type=source, typeName='source', location='classpath'}, PluginDesc{klass=class org.apache.kafka.connect.tools.MockConnector, name='org.apache.kafka.connect.tools.MockConnector', version='6.1.0-ccs', encodedVersion=6.1.0-ccs, type=connector, typeName='connector', location='classpath'}, PluginDesc{klass=class org.apache.kafka.connect.tools.MockSinkConnector, name='org.apache.kafka.connect.tools.MockSinkConnector', version='6.1.0-ccs', encodedVersion=6.1.0-ccs, type=sink, typeName='sink', location='classpath'}, PluginDesc{klass=class org.apache.kafka.connect.tools.MockSourceConnector, name='org.apache.kafka.connect.tools.MockSourceConnector', version='6.1.0-ccs', encodedVersion=6.1.0-ccs, type=source, typeName='source', location='classpath'}, PluginDesc{klass=class org.apache.kafka.connect.tools.SchemaSourceConnector, name='org.apache.kafka.connect.tools.SchemaSourceConnector', version='6.1.0-ccs', encodedVersion=6.1.0-ccs, type=source, typeName='source', location='classpath'}, PluginDesc{klass=class org.apache.kafka.connect.tools.VerifiableSinkConnector, name='org.apache.kafka.connect.tools.VerifiableSinkConnector', version='6.1.0-ccs', encodedVersion=6.1.0-ccs, type=source, typeName='source', location='classpath'}, PluginDesc{klass=class org.apache.kafka.connect.tools.VerifiableSourceConnector, name='org.apache.kafka.connect.tools.VerifiableSourceConnector', version='6.1.0-ccs', encodedVersion=6.1.0-ccs, type=source, typeName='source', location='classpath'}         at org.apache.kafka.connect.runtime.isolation.Plugins.connectorClass(Plugins.java:208)         at org.apache.kafka.connect.runtime.isolation.Plugins.newConnector(Plugins.java:180)         at org.apache.kafka.connect.runtime.AbstractHerder.getConnector(AbstractHerder.java:572)         at org.apache.kafka.connect.runtime.AbstractHerder.validateConnectorConfig(AbstractHerder.java:342)         at org.apache.kafka.connect.runtime.AbstractHerder.lambda$validateConnectorConfig$1(AbstractHerder.java:326)         at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)         at java.util.concurrent.FutureTask.run(FutureTask.java:266)         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)         at java.lang.Thread.run(Thread.java:748)

1. 일반 db에서 select * from 보다 select 칼럼명 from 보통 후자의 방법으로 원하는 칼럼들만 부르는 게 성능 면에서 더 뛰어난 게 아닌지 궁금합니다. 2. 복잡한 테이블에서 전체 칼럼의 갯수가 20~30개가 넘어가면 fetch join 방식보다 DTO로 직접 조회하시는 방법을 쓰시는지 궁금합니다. (fetch join으로 해도 성능이 원하는 만큼 안 나올때 DTO로 직접 조회 하시는건가요?) 3. JPA 관점에서 복잡한 테이블이나, 컬렉션 조회는 강좌에서처럼 최적화를 할 수 있지만. 일반 테이블 jpa에서는 보통 전체 엔티티를 불러올 수 밖에 없던데 1)전체 엔티티를 조회했을 때와 2)원하는 칼럼들만 조회했을 때의 성능차이가 미비한지 궁금합니다. 4. spring data jpa에서 Projections로 원하는 칼럼만 조회할 수 있던데 실무에서는 엔티티가 한 개이면서도 단순할 때 성능을 위해 많이 사용하시는지 궁금합니다.

Database "C:/Users/NOTE/test" not found, either pre-create it or allow remote database creation (not recommended in secure environments) [90149-200] 90149/90149 윈도우 쓰고 있습니다. 비슷한 문제 있으신 분들이 올려준 질문 글이랑 답변도 보고 따라해보는데 계속 이 오류가 떠서 연결이 안됩니다.. 이거 때문에 진도를 못나가고 있네요.. 어떻게 해야할까요ㅠㅠ

어떤 엔티티 클래스에 작성해야하나요? Order에 ManyToOne으로 묶여있는 member OneToMany로 묶여있는 OrderItems 둘다 작성이 돼 있어서 어떤 규칙으로 어떤 엔티티 클래스에 작성해야 하는지 궁금합니다.,

안녕하세요 영한님, 매번 강의를 보고 커뮤니티 게시판에서 다른분들의 질문을 보고 저도 모르는걸 새로 배워가고있는데요  질문글 중  ====================================== 실무에서 보면 throw new xxxxException을 했을 경우 이를 호출하는 메서드에 뻘겋게 throw하거나 try catch하라고해서 똑같이 throw해주거나 했던거같은데... MemberService는 왜 이런게 없을까요? ============================== 라는 내용에서 질문이 있습니다. 구글링으로 checked와 unchecked의 차이에 대해서 알아보았습니다. 다만 checked는트랜잭션에서 롤백이 안되고 unchecked는 롤백이 된다고 하는걸 알았습니다. 여기서 궁금한게 있습니다. 강의 18:17에 validateDuplicateMember 매소드 내에서 if(!findMember.isEmpty() 일 경우 uncheck 예외를 던지게 됩니다. 같은 Unchecked인 IndexOutOfBoundException의 경우 배열의 크기를 잘못 접근하면 try catch로 묶지 않았을 경우 프로그램이 종료가 되더라구요, 하지만 RunTimeException을 상속받는 IllegalStateException은 따로 try catch문으로 잡아주지 않아도 프로그램이 종료되지 않고 예외가 발생하면 이미 존재하는 회원입니다. 라는 로그를 볼 수있습니다. 스프링 내부 어디선가 throw new IllegalStateException을 받아주는것인가요? 받는다면 어디서 받아주는 것인가요?  감사합니다.

강의에서 구현한 MemberForm이 Dto와 같은 개념인가요?  MemberForm을 사용하신 이유에 대해 설명하신것을 들어보면 Dto와 같은 것 같은데 만약 같은것이면 왜 Dto라 명명하지 않으신건지, 혹은 Dto와 다른 개념이면 어떤 점이 다른것인지 궁금합니다.

계속 8080포트가 사용중이라 에러 메시지가 떠서 따로 cmd에서 포트 번호 확인해봤는데 8080포트는 나오지도 않습니다... 왜 이러는지 모르겠습니다...

@JsonFilter("UserInfo") 를 사용해서 기존에 개발했던 아래 함수를 호출 하니 에러가 발생합니다. 모델쪽에 JsonFilter를 사용하면 컨트롤러쪽에 MappingJacksonValue는 반듯이 사용해야 하는 건가요? @GetMapping("/users")public ResponseEntity<List<User>> retrieveAllUsers(){