안녕하세요. 계산기 코드에서, 소수점선택이랑, 0 을 선택하는 경우, floatNumber 는 해당값 인식이 안되어, 상단 currentDisplay에 표시가 안되고, 이후 다른 숫자를 누르면 소수점 및 0을 포함하여 floatNumber 값이 인식이 되어 상단에 함께 표시가 되던데요. 소수점은 아니더라도 소수점 이하 0을 눌렀을 때에 상단화면에 0까지를 바로 표시가 되도록 하려면 if 문으로 추가 코딩을 해야 하는 거겠죠??
학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문전에 다음을 꼭 확인해주세요. 1. 강의 내용과 관련된 질문을 남겨주세요. 2. 인프런의 질문 게시판과 자주 하는 질문(링크)을 먼저 확인해주세요. (자주 하는 질문 링크: https://bit.ly/3fX6ygx) 3. 질문 잘하기 메뉴얼(링크)을 먼저 읽어주세요. (질문 잘하기 메뉴얼 링크: https://bit.ly/2UfeqCG) 질문 시에는 위 내용은 삭제하고 다음 내용을 남겨주세요. ========================================= [질문 템플릿] 1. 강의 내용과 관련된 질문인가요? (예/아니오) 예 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오) 예 3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오) 예 [질문 내용] queryDsl 강의 중 조인편을 보면서 한가지 실험을 해봤습니다. @Test void 팀A에_소속된_모든_멤버를_조회힌다() { List<Member> found = jpaQueryFactory.selectFrom(member) .where(member.team.name.eq("teamA")) .fetch(); assertThat(found) .map(Member::getTeam) .extracting("name") .allMatch(teamName -> teamName.equals("teamA")); } @Test void 조인을_통해_팀A에_소속된_모든_멤버를_조회힌다() { List<Member> found = jpaQueryFactory.selectFrom(member) .join(member.team, team) .where(team.name.eq("teamA")) .fetch(); assertThat(found) .map(Member::getTeam) .extracting("name") .allMatch(teamName -> teamName.equals("teamA")); } 첫번째 테스트는 join 문 없이 QType 을 활용해서 where에 필요한 조건을 작성하였구요 두번째 테스트는 join 메서드를 활용한 것 입니다. 테스트 결과도 같고 실행 후 실제 수행된 쿼리도 동일하더라구요 이런 경우에는 어떤 방법이 더 적절할까요?
안녕하세요! 좋은 강의 감사합니다. 강의를 듣던 중 궁금한 점이 생겨 질문드립니다. 21:30 쯤 merge를 해서 메인 브랜치에 최종결과 코드를 릴리즈 했고 이게 delivery이다. 라고 해주셨는데 merge랑 delivery랑 같은 개념으로 생각해도 되는 건가요..? 둘이 같은거라면 CI/CD 파이프라인에서 왜 굳이 나누는 건지... merge랑 delivery의 차이가 뭔지 잘 모르겠습니다 ㅠㅠ
질문 답변을 제공하지만, 강의 비용에는 Q&A는 포함되어 있지 않습니다. 다만 실습이 안되거나, 잘못된 내용의 경우는 알려주시면 가능한 빠르게 조치하겠습니다! [질문 전 답변] 1. 강의에서 다룬 내용과 관련된 질문인가요? [ 예 | 아니요] 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? [ 예 | 아니요] 3. 질문 잘하기 법을 읽어보셨나요? [ 예 | 아니요] ( https://www.inflearn.com/blogs/1719 ) 4. 잠깐! 인프런 서비스 운영 관련 문의는 1:1 문의하기를 이용해주세요. [질문 하기] 7.4.프로메테우스 블랙박스 모니터링 수업에서 istio 설명을 그림쿠버에서 다루어서 넘어갔는데, 저는 그림쿠버를 구매하지 않아 이해가 잘 되지 않습니다. 개략적으로 어떤 기능을 담당하나요?
안녕하세요 강의 정말 잘 듣고 실무에서도 열심히 사용하고 있습니다. 강의에서 lazy loading과 fetch join을 활용하여 최적화 하는 부분에 대해서는 이해를 하고 있습니다. 그렇다면 eager loading은 사용을 피해야하는 걸까요? 아니면 어떤 케이스에 대해서는 즉시 로딩이 더 실무적으로 유용한 경우가 있을까요? 즉시 로딩이 사용을 지양해야 된다면 JPA에서 굳이 만들지 않았을 것 같은데 어떤 상황에서 사용해야할지에 대해 의문점이 듭니다. 제가 생각했을 땐 테이블 분리를 위해 엔티티를 나누었지만 항상 같이 조회되는 상황이나 OneToOne 상황에서는 크게 상관없을 것 같긴한데 필요없는 컬럼까지 즉시 로딩으로 가져오는게 성능에 크게 영향을 끼치는지에 대해 궁금합니다. 이외에도 실무적으로 이럴 땐 지연 로딩보단 즉시 로딩이 더 적합하다라는 상황이 있다면 조언 부탁드리겠습니다. 감사합니다!
select h.hacker_id, h.name from Submissions s inner join Hackers h on s.hacker_id = h.hacker_id inner join Challenges c on s.challenge_id = c.challenge_id inner join Difficulty d on c.difficulty_level = d.difficulty_level where d.score = s.score group by h.hacker_id having count(h.hacker_id) > 1 order by count(h.hacker_id) desc, h.hacker_id 제가 푼 답안인데 틀렸다고 나옵니다. group by h.hacker_id, h.name 2개를 해줘야 정답으로 나오는데 hacker_id만 그룹화 해서 묶어도 되는거 아닌가요? select 에 h.hacker_id, h.nam e 이 두개의 컬럼을 다 group으로 묶어줘야 되는 이유가 있나요? 이해가 되지 않습니다.
[질문 템플릿] 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의 메서드를 호출하면 이게 성능상 좋은가요?
안녕하세요, 양질의 강의 항상 감사드립니다! 다름이 아니라 현재 실무에서 스프링 배치를 이용해서 데이터를 DB to DB 로 마이그레이션하는 업무가 있는데 이를 강의에서 배운 카프카 커넥트를 활용하면 좋을것 같아서 고민중인데 잘 안풀리는 부분이 있어 질문드립니다 데이터 가공문제 DB to DB 로 이관시 가장 좋은것은 커넥트만 써서 코드개발없이 마이그레이션 해버리는 것이 좋을것같은데 막상 실제 마이그레이션 할 때는 source 에서 퍼온 데이터를 sink 시 몇몇 컬럼은 데이터 가공하거나 없어지는 등 가공에 약간 손을 봐야하는 경우가 종종 있어서 이런 케이스에 대해 어떻게 해결을 해야할 지 고민입니다. 고민을 해봤을 때 해결방안으로는 streams api 를 껴서 아래와 같은 아키텍쳐로 해결하는 방법이 있을 것 같은데요 source -> topic -> kafka stream api 등을 통해 데이터 가공 후 topic 전송 -> sink 커스텀 sink 나 source 커넥터 개발 어느 방법이나 결국 추가개발이 필요한건 매한가지라 현재 배치로 개발해놓은 구조를 커넥트를 이용하도록 바꿨을 때 이점이 명확하게 안보여서 좀 고민입니다... 데이터 마이그레이션 후 검증문제 실무에서 배치로 마이그레이션 후 원본데이터가 있는 source db 와 마이그레이션 한 sink db 간에 건수비교 등 데이터 이관이 잘 되었는지 대사비교를 진행하는데요, 카프카 커넥트로 전환한다고 해도 이러한 대사비교는 여전히 필요하지 않을까 싶은데 실무에서 카프카 커넥트를 활용할 때 이러한 검증 문제를 어떻게 해결하는지 궁금합니다 카프카 커넥트를 실무에서 활용한 경험이 없다보니.... 강사님이라면 이러한 문제에 직면했을때 어떤 생각을 가지실 지 궁금합니다! 감사합니다:)